【MySQL】我必须得告诉大家的MySQL优化原理2（中）存储过程和触发器

前言：

在合适的场景下使用合适的方法，不抱偏见。

第二个问题，有非常多的人在分享时都会抛出这样一个观点：尽可能不要使用存储过程，存储过程非常不容易维护，也会增加使用成本，应该把业务逻辑放到客户端。既然客户端都能干这些事，那为什么还要存储过程？

CHEN川大佬……算了，我还转载吧，不浓缩了：

如果有深入了解过存储过程，就会发现存储过程并没有大家描述的那么不堪。我曾经经历过一些重度使用存储过程的产品，依赖到什么程度呢？就这么说吧，上层的应用基本上只处理交互与动效的逻辑，所有的业务逻辑，甚至是参数的校验均在存储过程中实现。曾经有出现过一个超大的存储过程，其文件大小达到惊人的80K，可想而知，其业务逻辑有多么复杂。在大多数人眼中，这样的技术架构简直有点不可理喻，但实际上这款产品非常成功。

其成功的原因在一定程度上得益于存储过程的优点，由于业务层代码没有任何侵入业务的代码，在不改变前端展示效果的同时，可以非常快速的修复BUG、开发新功能。由于这款产品需要部署在客户的私有环境上，快速响应客户的需求就变得尤为重要，正是得益于这种架构，可以在客户出现问题或者提出新需求时，快速响应，极端情况下，我们可以在1小时内修复客户遇到的问题。正是这种快速响应机制，让我们获得大量的客户。

 

当然存储过程还有其他的优点，比如，可以非常方便的加密存储过程代码，而不用担心应用部署到私有环境造成源代码泄露、可以像调试其他应用程序一样调试存储过程、可以设定存储过程的使用权限来保证数据安全等等。一切都非常美好，但我们的产品是基于MS SQL SERVER实现的，其可以通过T-SQL非常方便的实现复杂的业务逻辑。你可以把T-SQL看做是一门编程语言，其包含SQL的所有功能，还具备流程控制、批处理、定时任务等能力，你甚至可以用其来解析XML数据。关于T-SQL的更多信息可以参考MSDN，主流的关系型数据库目前只有MS SQL SERVER支持T-SQL，因此，MySQL并不具备上文描述的一些能力，比如，MySQL的存储过程调试非常不方便（当然可以通过付费软件来获得很好的支持）。

 

除此之外，MySQL存储过程还有一些其他的限制：

• 优化器无法评估存储过程的执行成本
• 每个连接都有独立的存储过程执行计划缓存，如果有多个连接需要调用同一个存储过程，将会浪费缓存空间来缓存相同的执行计划

 

因此，在MySQL中使用存储过程并不是一个太好策略，特别是在一些大数据、高并发的场景下，将复杂的逻辑交给上层应用实现，可以非常方便的扩展已有资源以便获得更高的计算能力。而且对于熟悉的编程语言，其可读性会比存储过程更好一些，也更加灵活。不过，在某些场景下，如果存储过程比其他实现会快很多，并且是一些较小的操作，可以适当考虑使用存储过程。

 

触发器

和存储过程类似的，还有触发器，触发器可以让你在执行INSERT、UPDATE和DELETE时，执行一些特定的操作。在MySQL中可以选择在SQL执行之前触发还是在SQL执行后触发。触发器一般用于实现一些强制的限制，这些限制如果在应用程序中实现会让业务代码变得非常复杂，而且它也可以减少客户端与服务器之间的通信。MySQL触发器的实现非常简单，所以功能非常有限，如果你在其他数据库产品中已经重度依赖触发器，那么在使用MySQL触发器时候需要注意，因为MySQL触发器的表现和预想的不一致。

首先对一张表的每一个事件，最多只能定义一个触发器，而且它只支持“基于行的触发”，也就是触发器始终是针对一条记录的，而不是针对整个SQL语句。如果是批量更新的话，效率可能会很低。其次，触发器可以掩盖服务器本质工作，一个简单的SQL语句背后，因为触发器，可能包含了很多看不见的工作。再者，触发器出现问题时很难排查。最后，触发器并不一定能保证原子性，比如MyISAM引擎下触发器执行失败了，也不能回滚。在InnoDB表上的触发器是在同一个事务中执行完成的，所以她们的执行是原子的，原操作和触发器操作会同时失败或者成功。

虽然触发器有这么多限制，但它仍有适用的场景，比如，当你需要记录MySQL数据的变更日志，这时触发器就非常方便了。

 

小结：

在合适的场景下使用合适的方法，不抱偏见。

 

作者：CHEN川
链接：https://www.jianshu.com/p/01b9f028d9c7
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。