max_execution_time 仅对独立执行的 select 语句生效，不适用于存储过程、触发器、函数内或 insert/update/delete 中的 select；优先级为语句级 > 会话级 > 全局设置。
max_execution_time 对哪些 SQL 真的有效？
max_execution_time 只对**独立执行的 SELECT 语句**生效，不是所有“读操作”都管用。
- ✅ 生效场景：客户端直连后执行的普通
SELECT，比如SELECT * FROM users WHERE id = 123 - ❌ 不生效场景：
SELECT在存储过程、触发器、函数内部调用；INSERT ... SELECT中的SELECT部分；任何带写操作（UPDATE/DELETE）的语句本身完全无视该参数 - ⚠️ 特别注意：即使你在存储过程中显式写了
SET SESSION max_execution_time = 500，里面的SELECT依然不会被中断——这是 MySQL 的硬限制，不是配置没生效
三种设置方式的区别和优先级
全局、会话、语句级三者共存时，优先级是：语句级提示 > 会话级设置 > 全局设置。
-
SET GLOBAL max_execution_time = 2000：影响后续所有新连接，重启失效（除非用SET PERSIST） -
SET SESSION max_execution_time = 1000：只对当前连接有效，断开即丢，适合临时调试 -
SELECT /*+ MAX_EXECUTION_TIME(300) */ ...：只约束这一条语句，最精准，但要求 MySQL ≥ 5.7.8 - ⚠️ 坑点：
SET PERSIST max_execution_time = 1000虽然能持久化，但仅对支持PERSIST的变量生效（5.7.8+），且需有SYSTEM_VARIABLES_ADMIN权限
超时了但没报错？可能是这些原因
你设了 max_execution_time = 500，结果一条慢 SELECT 还是跑了 3 秒才停——这不是 bug，是设计行为。
- MySQL 不是实时中断，而是在查询执行的「检查点」（如扫描完一个数据页、完成一次索引遍历）才判断是否超时，所以实际耗时可能略超设定值
- 如果查询卡在系统调用（比如磁盘 I/O 等待、锁等待），
max_execution_time完全不计时，它只统计 MySQL 内核执行 SQL 的 CPU 时间 - 错误码固定是
ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded，不是超时就一定报这个，也可能是被pt-kill或KILL QUERY干掉的
排查真正超时的 SQL，别只盯 max_execution_time
靠 max_execution_time 防不住大部分问题，它只是最后一道闸门。真要定位谁在拖慢数据库，得看更底层的线索。
- 开慢查询日志：
SET GLOBAL slow_query_log = 'ON'+SET GLOBAL long_query_time = 2，它记录的是真实 wall-clock 时间，比max_execution_time更反映用户体验 - 查实时长事务：
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE TIME > 60，直接看到卡了多久的连接 - 用 Performance Schema 找“伪快实慢”的语句：
SELECT DIGEST_TEXT, AVG_TIMER_WAIT/1000000000 AS avg_ms, SUM_ROWS_EXAMINED FROM performance_schema.events_statements_summary_by_digest ORDER BY AVG_TIMER_WAIT DESC LIMIT 5，高SUM_ROWS_EXAMINED低avg_ms往往意味着全表扫得勤但单次快，容易突发打满 IO - ⚠️ 别依赖通用日志（
general_log）做常态化监控，它一开性能掉 30% 以上，只适合抓包式排查
真正难搞的不是“怎么设超时”，而是“为什么这条 SQL 总是卡在临界点”。max_execution_time 给你的是止损手段，不是诊断工具——它关得掉查询，关不掉根因。
