开发者社区> 问答> 正文

为什么不推荐使用MySQL触发器而用存储过程?

不止一次在各大论坛,文章中看到大多数人不推荐触发器,统统推荐存储过程。
现在的场景是:1000万数据,1万并发的规模。疑问:
触发器本身就是特殊的存储过程,那么如果业务逻辑本身不需要定义变量,不需要定义事务,仅仅需要for each row /update/delete/insert,仅仅需要触发器的情况下,还要特定使用存储过程吗?
还是说触发器本身具有特别大的性能问题呢?

展开
收起
蛮大人123 2016-02-12 11:46:56 6019 0
1 条回答
写回答
取消 提交回答
  • 码农|Coder| Pythonista

    1.存储过程和触发器二者是有很大的联系的,我的一般理解就是触发器是一个隐藏的存储过程,因为它不需要参数,不需要显示调用,往往在你不知情的情况下已经做了很多操作。从这个角度来说,由于是隐藏的,无形中增加了系统的复杂性,非DBA人员理解起来数据库就会有困难,因为它不执行根本感觉不到它的存在。
    2.再有,涉及到复杂的逻辑的时候,触发器的嵌套是避免不了的,如果再涉及几个存储过程,再加上事务等等,很容易出现死锁现象,再调试的时候也会经常性的从一个触发器转到另外一个,级联关系的不断追溯,很容易使人头大。其实,从性能上,触发器并没有提升多少性能,只是从代码上来说,可能在coding的时候很容易实现业务,所以我的观点是:摒弃触发器!触发器的功能基本都可以用存储过程来实现。
    3.在编码中存储过程显示调用很容易阅读代码,触发器隐式调用容易被忽略。
    存储过程也有他的致命伤↓
    4.存储过程的致命伤在于移植性,存储过程不能跨库移植,比如事先是在mysql数据库的存储过程,考虑性能要移植到oracle上面那么所有的存储过程都需要被重写一遍。

    2019-07-17 18:41:15
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
搭建电商项目架构连接MySQL 立即下载
搭建4层电商项目架构,实战连接MySQL 立即下载
PolarDB MySQL引擎重磅功能及产品能力盛大发布 立即下载

相关镜像