max_execution_time对存储过程完全无效，因其仅作用于独立只读select语句；存储过程内的语句属子执行单元，绕过超时检查路径，官方明确声明忽略；替代方案包括event轮询processlist主动kill query，或在过程内手动埋点检测时间并leave退出。
max_execution_time 对存储过程完全无效 —— 这不是配置错误，也不是权限缺失，而是 MySQL 官方明确限定的行为边界。
max_execution_time 的真实作用范围
- 仅对独立执行的、只读的
SELECT语句生效 - 不作用于任何嵌套在存储过程、函数、触发器或事务块中的语句
- 即使存储过程里只有一行
SELECT SLEEP(30)，也不会被中断 -
SET SESSION max_execution_time = 5000放在存储过程开头，纯属无效操作 - 同样，
/<em>+ MAX_EXECUTION_TIME(5000) </em>/这类 hint 无法注入到过程体内部，语法上就不被允许
你看到的“设置后没反应”，不是环境问题，是机制本就不覆盖该场景。
为什么 SET SESSION max_execution_time 在存储过程中不生效
- MySQL 的超时检查只发生在顶层语句解析阶段
- 存储过程内所有语句都属于子执行单元（substatement），绕过该检查路径
- 官方文档原文：
max_execution_time is ignored for SELECT statements in stored programs - 它不判断语句是否真的慢，只看“是不是裸 SELECT”——这是设计决定，不是 bug
哪怕你用 mysql -e "SET SESSION max_execution_time=1000; CALL my_proc();" 调用，也一样无效。
替代方案：用 INFORMATION_SCHEMA.PROCESSLIST 主动杀查询
这是目前最通用、无需外部依赖的落地方式：
- 创建一个监控存储过程，例如
kill_long_running_procedure - 用游标扫描
INFORMATION_SCHEMA.PROCESSLIST，筛选条件如：COMMAND = 'Query'-
TIME > 120（单位秒） -
INFO LIKE 'CALL %'或按用户/数据库过滤，避免误杀
- 对匹配到的
ID执行KILL QUERY @id（注意不是KILL @id，后者会断连） - 再创建一个每 5 秒触发一次的
EVENT，调用该过程
关键提醒：
-
KILL QUERY只终止当前正在执行的语句，不会回滚整个事务 - 若存储过程已修改数据并处于事务中，需自行保证一致性（比如加标记表、幂等逻辑）
更可控的方式：在存储过程中手动埋点检测
如果你能修改存储过程源码，这是最精准、最轻量的方案：
- 开头声明起始时间：
DECLARE start_ts DATETIME DEFAULT NOW(); - 在长耗时操作前插入判断，例如：
IF TIMESTAMPDIFF(MICROSECOND, start_ts, NOW()) > 10000000 THEN LEAVE main_label; END IF; - 配合
main_label: BEGIN ... END和LEAVE/ITERATE控制流程 - 特别适合含循环、大表扫描、多次远程调用的复杂过程
这种方式完全避开 MySQL 超时机制的限制，但要求你对过程逻辑有掌控权，且需预留检测点。
真正容易被忽略的是：超时控制必须和事务行为对齐。KILL QUERY 可能留下部分更新的脏状态；手动埋点若放在事务外，也可能导致状态不一致。
无论选哪种方案，都要结合你的存储过程是否写数据、是否可重入、是否有补偿机制来定。
