max_execution_time仅对独立SELECT/UPDATE/DELETE/INSERT SELECT语句生效，无法中断存储过程内的WHILE循环或纯计算逻辑；它在5.7.8+原生MySQL中强制终止超时语句并释放锁，返回ERROR 3024，但不支持函数、触发器及DDL。
MySQL 里真正在跑的死循环 SQL（比如存储过程卡在 WHILE 里出不来），靠等它自己结束基本没戏；但你不需要手动盯屏或写脚本轮询，max_execution_time 是 MySQL 5.7.8+ 原生支持的“熔断开关”，能直接从服务端强制中止超时语句。
为什么 max_execution_time 比 KILL 更安全可靠
它作用于单条语句级别，不中断连接、不丢事务上下文、不触发连接重置——和 KILL QUERY 行为一致，但无需人工判断时机。而 KILL CONNECTION 会干掉整个会话，可能让应用误判为网络故障，还可能丢掉未提交的事务状态。
-
max_execution_time是 session 级变量，可对高风险查询单独设限，不影响其他语句 - 它只对 SELECT、UPDATE、DELETE、INSERT ... SELECT 生效，对存储过程内部的循环体无效（这点必须清楚）
- 若语句已开始执行并持有锁，超时后 MySQL 会立即释放该语句持有的所有行锁/表锁，避免阻塞下游
- 超时触发时返回错误：
ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded
如何在存储过程中让 max_execution_time 生效
关键点：不能指望它去拦 WHILE 循环本身，但可以拦住循环体内反复执行的 SQL。比如你在循环里查表、更新状态、调用函数——这些子语句都受控。
- 在存储过程开头加：
SET SESSION max_execution_time = 5000;（单位毫秒，这里设 5 秒） - 确保循环内每次执行的 SQL 都是独立语句，不要拼成超长动态 SQL 后用
EXECUTE——那整条EXECUTE才算一条语句，超时阈值就失去意义 - 如果循环里有
SELECT ... INTO或INSERT ... SELECT，它们都会被单独计时；但纯赋值如SET @i = @i + 1;不计入 - 注意：若存储过程里用了游标（
DECLARE cursor_name CURSOR FOR SELECT ...），那个SELECT在声明时就被计时了，不是在FETCH时才开始
排查时发现 max_execution_time 没起作用？检查这几点
常见失效不是参数没设，而是语句类型或执行路径绕过了限制。
- 确认当前 MySQL 版本 ≥ 5.7.8：
SELECT VERSION(); - 检查是否在事务里执行了 DDL（如
ALTER TABLE）——这类语句不支持max_execution_time - 确认没在存储函数或触发器中调用该语句：函数/触发器内该变量会被忽略
- 查看是否启用了
sql_log_bin = OFF：某些复制场景下该限制可能被跳过 - 别和
innodb_lock_wait_timeout混淆——后者管的是“等锁超时”，不是“执行超时”
真正难处理的，是那些不发 SQL、只做计算的纯逻辑死循环（比如 WHILE @i ），这种 <code>max_execution_time 完全无效，只能靠 SHOW PROCESSLIST 抓 State: Executing + Time 持续上涨来人工干预。所以写循环时，变量初始化、退出条件、中间打点，一个都不能少。
