MySQL 5.7+ 用 max_execution_time 控制 SELECT 超时，仅对最外层 SELECT 生效，单位毫秒，支持全局、会话、语句级（Hint）设置；但锁等待、子查询、旧版本等场景不触发，需配合 pt-kill 和多层验证。
MySQL 5.7+ 怎么用 max_execution_time 控制单条 SELECT 超时
这个参数只对 SELECT 语句生效，且仅在服务器端强制中断执行（不是客户端断连），但默认值是 0（不限制）。它不作用于 INSERT、UPDATE、DELETE，也不影响存储过程内部的语句。
实操建议：
- 全局设置：执行
SET GLOBAL max_execution_time = 3000;（单位毫秒），但需有SUPER权限，且新连接才继承该值 - 会话级更常用：连接后立刻执行
SET SESSION max_execution_time = 2000;，避免影响其他业务连接 - 语句级最精准：在 SQL 前加
/*+ MAX_EXECUTION_TIME(1500) */ SELECT ...（MySQL 5.7.8+，需启用optimizer_switch中的hint_tables） - 注意：如果查询已进入锁等待（如等
row lock），超时计时器可能暂停，实际耗时会远超设定值
为什么 max_execution_time 对某些慢查询完全没反应
常见错误现象是设了 1000 毫秒却仍有 10 秒的查询跑完——大概率因为该查询没走「执行阶段」的超时判定路径。
典型场景包括：
- 查询被阻塞在
Waiting for table metadata lock或Waiting for row lock状态，此时还没真正开始执行，max_execution_time不计时 - 使用了
UNION、子查询或派生表，而超时提示只作用于最外层SELECT，内层仍可无限执行 - 开启了
read_only或从库延迟复制，部分优化器路径绕过超时检查（尤其 MySQL 5.7.20 前的版本） - 客户端设置了
wait_timeout或interactive_timeout，误以为是它在 kill 查询，其实是连接被断开，SQL 可能仍在服务端残留运行
替代方案：用 pt-kill 实时捕获并终止慢查询
当 max_execution_time 覆盖不到的场景（比如 DML 慢、锁等待长、老版本 MySQL），pt-kill 是更可靠的兜底手段。
实操建议：
- 基础命令：
pt-kill --host=localhost --user=admin --password=*** --busy-time 5 --kill，表示杀掉持续运行超 5 秒的连接 - 加条件过滤更安全：
--match-command Query --match-state executing --ignore-command Sleep，避免误杀空闲连接 - 务必先试运行：
--dry-run查看哪些线程会被杀，再删掉它加--kill - 性能影响小，但要注意：它依赖
SHOW PROCESSLIST，高并发下可能漏检；且杀的是整个连接，不是单条语句，若应用没做重连/事务回滚，可能引发数据不一致
监控和验证超时是否真正生效
光设参数不验证，等于没设。最容易忽略的是没确认超时是否触发了 Killed 状态，而不是静默失败或客户端报错不明确。
验证步骤：
- 开一个新连接，执行
SET SESSION max_execution_time = 1000; - 运行模拟慢查：
SELECT SLEEP(2);（注意：SLEEP 是函数，不是真实慢查，但能触发超时机制） - 立刻查
SHOW PROCESSLIST;，看到该线程状态变成Killed，而非Query或Locked - 客户端收到的错误信息必须是
ERROR 1317 (70100): Query execution was interrupted，不是Lost connection或Timeout expired - 日志里不会记录到
slow_query_log，因为它没跑完，但可开启general_log抓取中断前的原始语句
超时控制不是一设就灵的事，特别是涉及锁、复制、Hint 解析这些隐性路径时，max_execution_time 的边界比文档写的更窄。真要防住所有慢查询，得把语句级超时、连接级 kill、应用层 timeout 三层都配齐，而且每层都要单独验证。
