MySQL判断SQL该被超时中断靠max_execution_time（控制执行时长，仅SELECT生效，毫秒级，需显式设置）和wait_timeout（仅断开空闲连接，不干预运行中查询），二者职责分离、不可互替。
MySQL怎么判断SQL该被超时中断？
靠的是两个独立但协同的会话级超时参数：wait_timeout 和 max_execution_time。前者管“空闲多久断连”，后者才真正控制“执行多久强制终止”。很多同学混淆这两者，结果调了 wait_timeout 却发现长查询照样跑满10分钟——因为那根本不是它管的事。
实际生效逻辑是：只要 SQL 正在执行（非空闲状态），wait_timeout 就不计时；而 max_execution_time 从语句开始解析那一刻起倒计时，超时即触发 KILL QUERY 级别中断，不等事务提交也不管锁是否释放。
-
max_execution_time默认为 0（禁用），必须显式设置才生效，单位毫秒 - 它只对单条 SELECT 生效（MySQL 5.7+），INSERT/UPDATE/DELETE 不受控，需靠应用层或
innodb_lock_wait_timeout配合 - 若 SQL 已进入锁等待（如 State = 'Locked'），计时器暂停，直到拿到锁才继续倒数——这点常被忽略，导致误判“超时没起作用”
如何给某条SQL加执行时间限制？
有三层控制粒度，按优先级从高到低：语句级 > 会话级 > 全局级。生产中推荐语句级，避免全局配置误伤其他业务。
- 语句级：在 SQL 前加
/*+ MAX_EXECUTION_TIME(3000) */（MySQL 5.7+ 支持 optimizer hint） - 会话级：执行
SET SESSION max_execution_time = 3000;，后续所有 SELECT 生效，直到会话结束 - 全局级：执行
SET GLOBAL max_execution_time = 3000;，新连接继承，但已有连接不受影响
注意：hint 方式最精准，但要求 SQL 是客户端直接发送的原始文本；如果 ORM 拼装过（比如 SQLAlchemy 加了额外注释或换行），hint 可能失效。
超时中断后为什么还会看到“Killed”状态？
这是 MySQL 的清理机制延迟导致的假象。Killed 不代表立即退出，而是标记为“待终止”。真实退出时机取决于当前执行阶段：
- 若正在做磁盘 I/O（如读取大 BLOB、写临时表），会等这一批次完成再退出
- 若正持有行锁或表锁，会先尝试释放，但若其他事务正在等这把锁，可能卡在
Rolling back状态几十秒 - MySQL 8.0.28+ 引入了
kill_query_on_timeout参数，设为ON可强制跳过部分清理步骤，但风险是可能留下未释放的锁资源
所以监控里看到 State = 'Killed' 持续超过 5 秒，基本可以判定它卡在 I/O 或锁清理环节，而不是“没中断成功”。
为什么有些SQL超时了却没被中断？
常见于三类场景，和参数本身无关，而是 MySQL 的底层行为限制：
- DML 语句（UPDATE/DELETE）默认不响应
max_execution_time，除非开启innodb_rollback_on_timeout并配合事务拆分 - 存储过程内部的 SELECT，即使加了 hint，也可能被过程体封装屏蔽，需在过程定义时用
SET SESSION max_execution_time - 使用了
UNION或子查询的复杂 SELECT，优化器可能将 timeout 仅施加在外层，内层仍自由运行
最隐蔽的坑是：当 SQL 被 max_execution_time 中断后，如果应用没捕获 ERROR 1317 (70100): Query execution was interrupted，而是当成普通失败重试，就可能形成“中断→重试→再中断”的雪崩循环。
