MySQL进阶：4.为什么不推荐使用存储过程和触发器

青旅半醒 2023-02-23 12:30 12阅读 0赞

【专栏目录】  
[MySQL进阶：1.MySQL基础环境搭建][MySQL_1.MySQL]  
[MySQL进阶：2.索引][MySQL_2.]  
[MySQL进阶：3.视图][MySQL_3.]  
[MySQL进阶：4.为什么不推荐使用存储过程和触发器][MySQL_4.]  
[MySQL进阶：5.存储引擎][MySQL_5.]  
[MySQL进阶：6.定位SQL性能问题][MySQL_6._SQL]  
[MySQL进阶：7.SQL优化][MySQL_7.SQL]

> 以下内容摘自:[为什么大家都不推荐使用MySQL触发器而用存储过程？][MySQL]，侵权立删。

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

`总结：只有在并发不高的项目，管理系统中用。如果是面向用户的高并发应用，都不要使用。触发器和存储过程本身难以开发和维护，不能高效移植。触发器完全可以用事务替代。存储过程可以用后端脚本替代。`

[MySQL_1.MySQL]: https://blog.csdn.net/w_y_x_y/article/details/107048525
[MySQL_2.]: https://blog.csdn.net/w_y_x_y/article/details/107048532
[MySQL_3.]: https://blog.csdn.net/w_y_x_y/article/details/107188936
[MySQL_4.]: https://blog.csdn.net/w_y_x_y/article/details/107188957
[MySQL_5.]: https://blog.csdn.net/w_y_x_y/article/details/107188967
[MySQL_6._SQL]: https://blog.csdn.net/w_y_x_y/article/details/107188979
[MySQL_7.SQL]: https://blog.csdn.net/w_y_x_y/article/details/107214956
[MySQL]: https://segmentfault.com/q/1010000004907411