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

问题描述

问 题

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

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

解决方案

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

这篇关于为什么大家都不推荐使用MySQL触发器而用存储过程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！