MySQL中max_execution_time引发的血案

一、场景描述

今日，MySQL存储节点因CPU持续100%使用率而触发了报警，持续时间长达数小时。通过在控制台中执行show processlist命令查看当前进程，发现有许多相同的SQL查询正在运行，且执行时间均超过数小时。

二、问题分析

通常，用户会设置一个超时时间，接口不会无限等待，以确保良好的用户体验。这包括前端请求的超时时间和nginx的请求超时时间。然而，大家是否思考过，当HTTP请求断开时，接口中涉及的SQL查询是继续执行还是会断开连接呢？

三、问题根源

答案是肯定的，SQL查询一旦开始执行，除非应用程序发送kill命令，否则它将一直执行直到超时。那么，这个超时时间由哪个字段决定呢？我们来看一下MySQL5.7的官方说明：

在MySQL5.7中，超时时间由max_execution_time决定。如果将其设置为0，则不会有任何限制，查询会一直执行下去。

四、解决方案

通常，数据库层面的配置会设置一个可接受的最大值，以兼容所有应用程序，不可能针对单个应用或接口进行设置。那么，如何在应用级别和接口级别设置查询超时呢？

4.1 应用级别超时

以druid连接池为例，若要设置应用级别的查询超时，可以添加以下配置：

# SQL执行超时时间，针对所有CRUD
spring.datasource.druid.query-timeout=300

但这种配置有一个缺点，即它不仅适用于SELECT查询，还包含所有CRUD操作。

4.2 接口级别超时

在接口级别，可以使用setQueryTimeout属性为SQL查询设置超时时间。这个属性的作用与应用全局配置类似，但它仅针对特定的SQL查询。我们只需为SELECT查询设置此字段即可。

五、产品设计思考

还有一点值得分享的是，非技术层面的思考。为什么线上会出现那么多相同的SQL查询，并且不断执行？这是因为用户一旦发现某个操作长时间没有结果，就会不断重试，导致情况越来越糟。这也是为什么一旦系统出现问题，会迅速爆发，直到系统崩溃。因此，在产品设计方面也需要进行一些优化和限制。

六、总结

今天分享了三种设置SQL查询超时的方法：数据库层的max_execution_time、druid连接池的spring.datasource.druid.query-timeout、以及接口级别的setQueryTimeout。除了技术层面，产品设计方面也需要进行权衡和优化。

以上就是MySQL中max_execution_time引发的血案的详细内容，更多请关注php中文网其它相关文章！