为什么大家都不推荐使用MySQL触发器而用存储过程？

Question

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

还是说触发器本身具有特别大的性能问题呢？

Answer 1

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

Answer 2

我建议都不要用为好。

这种东西只有在并发不高的项目，管理系统中用。

如果是面向用户的高并发应用，都不要使用。

触发器和存储过程本身难以开发和维护，不能高效移植。

触发器完全可以用事务替代。
存储过程可以用后端脚本替代。

Answer 3

我觉得来自两方面的因素：
1- 存储过程需要显式调用，意思是阅读源码的时候你能知道存储过程的存在，而触发器必须在数据库端才能看到，容易被忽略。
2- Mysql的触发器本身不是很好，比如after delete无法链式反应的问题。
我认为性能上其实还是触发器占优势的，但是基于以上原因不受青睐。