为何MySQL的MAX_EXECUTION_TIME会缩短SLEEP时长而非抛出错误？

1. MAX_EXECUTION_TIME的实际定义 #

MAX_EXECUTION_TIME是MySQL专为只读SELECT语句（不含SELECT ... INTO等会修改数据的语句）设置的服务器端执行时长阈值，单位为毫秒。

• 默认值0表示无执行时间限制，可通过SHOW VARIABLES LIKE 'MAX_EXECUTION_TIME';查看当前会话或全局的设置值。
• 它监控的是查询在服务器端的实际执行时长，当达到阈值时，MySQL会主动终止查询的执行流程，但不会抛出硬错误，而是返回截至终止时已生成的结果集（若有）。

2. 为何缩短SLEEP时长而非报错？复杂查询的表现及如何判断未完成？ #

关于SLEEP()的特殊表现 #

SELECT SLEEP(30);属于特殊的只读语句，它的执行逻辑是让会话休眠指定时长。当MAX_EXECUTION_TIME触发终止时，MySQL会直接中断休眠流程，返回空结果集（因为SLEEP本身不产生业务数据），因此客户端会显示“执行成功”，但耗时等于设置的阈值时长。

复杂SELECT查询的表现 #

对于常规复杂查询（如大表全扫描、多表关联、聚合计算等），当达到时间阈值时，MySQL会终止查询执行，返回截至终止时已检索到的部分结果，同样不会抛出错误。例如，查询一个百万行表的全量数据，若设置阈值为1秒，会返回1秒内扫描到的部分行数据。

如何判断查询被截断未完成？ #

• 执行SHOW WARNINGS;：查询被MAX_EXECUTION_TIME终止时，会话会生成一条Note级别的警告，内容类似Query execution was interrupted, maximum statement execution time exceeded。
• 对比执行指标：查看SHOW SESSION STATUS LIKE 'Rows_examined';的结果，若实际扫描行数远小于预期的表总行数，说明查询被提前终止；也可通过Performance Schema的events_statements_history表查看查询的实际执行时长，确认是否等于设置的阈值。

3. 设计这种行为而非直接抛错的原因 #

MySQL选择柔性终止查询并返回部分结果，而非抛出硬错误，主要基于以下考量：

• 部分结果具备实用性：对于报表、数据分析类场景，即使查询未完成，已返回的部分数据仍可能有参考价值，比完全无结果更友好。
• 降低应用崩溃风险：多数应用未针对“查询超时报错”做专门处理，直接抛错可能导致应用异常；返回部分结果可让应用正常处理，仅需后续判断数据完整性。
• 只读场景的安全性：只读查询不会修改数据，终止执行不会引发数据一致性问题，可安全返回已生成的结果。
• 柔性资源管控：作为资源限制手段，柔性终止比硬中断更符合管控逻辑，允许用户调整阈值或优化查询，而非直接阻断业务。

内容的提问来源于stack exchange，提问作者Han Han