当MySQL的用户由于where条件设置不当或者执行了非常复杂的查询、聚合统计或者数据导出等慢查询时，会导致MySQL中进行全表扫描、大量数据计算等，进而会拖慢MySQL或者直接把MySQL干死，而不能服务。
在MySQL 5.7版本，之前一直没有太有效的手段来保护MySQL免受这种大量慢查询的蹂躏，因此MySQL数据库相当脆弱，并且MySQL数据库的性能和稳定性严重依赖于用户发起的查询类型。另外，只要你的慢查询一直运行，name该慢查询对应的MySQL连接就会被一直block住。
你可以google或者度娘该问题的解决方案，但是千篇一律的都是：执行一个daemon进程或者一个cronjob来周期性的监控processlist，并且将processlist中执行long query的process进行kill掉。这种方式简单而有效，刚毕业的应届生也能想到。但是这种方式太过粗鲁，因为你并不知道你将要kill的query是谁在运行，以及为什么运行。所以这种方式是最初级的数据库工程师采取的方式。
因此我们需要基于查询上下文对查询进行更细粒度的超时控制。这样才能真正体现一个专业的数据库工程师的素养。
使用MySQL 5.7，你可以通过使用一个新的查询优化hint来基于查询上下文自定义查询超时时间，超时的单位是毫秒，具体可以参考： 配置查询执行的超时时间 :
SELECT /*+ MAX_EXECUTION_TIME(1000) */ status, count(*) FROM articles GROUP BY status ORDER BY status;
这种在查询优化hint只对于select进行设置。
或者你也可以进行 session级别 或者 global 级别的查询超时设置:
SET SESSION MAX_EXECUTION_TIME=2000;
SET GLOBAL MAX_EXECUTION_TIME=2000;
若你的查询执行了很长时间，超过了MAX_EXECUTION_TIME设置的值，那么你的查询将会失败，并且抛出如下错误：
ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded
当然你可以在应用中对该错误进行正确的处理并且向应用的前端用户进行合理地阐释。
网友评论