max_execution_time 对存储过程完全无效，因其仅作用于独立执行的只读 SELECT 语句；存储过程内的 SELECT、函数、触发器及事务块均忽略该参数，且 MAX_EXECUTION_TIME hint 同样不生效。
max_execution_time 对存储过程完全无效 —— 这是 MySQL 官方明确声明的行为，不是配置遗漏或权限问题。
MySQL 的 max_execution_time 只作用于**独立执行的只读 SELECT 语句**。一旦 SELECT 被包裹在存储过程、函数、触发器或事务块中，该参数就直接被忽略。哪怕你在存储过程开头写上 SET SESSION max_execution_time = 1000，也起不到任何中断效果。
为什么 SET SESSION max_execution_time 在存储过程中不生效
根本原因在于执行上下文：MySQL 的超时检查机制只在“顶层语句解析阶段”触发，而存储过程内部的语句属于子执行单元（substatement），不参与该检查路径。官方文档原文明确写着：max_execution_time is ignored for SELECT statements in stored programs。
- 它不区分语句是否耗时，只看是否“裸 SELECT”
- 即使存储过程里只有一条
SELECT SLEEP(10)，也不会被中断 -
MAX_EXECUTION_TIMEhint 同样无效 —— hint 只能加在顶层语句上，无法注入到存储过程体内部
替代方案：用 EVENT + PROCESSLIST 主动杀查询
既然 MySQL 不提供原生支持，就得靠外部轮询+主动干预。核心思路是：定期扫描 INFORMATION_SCHEMA.PROCESSLIST，找出运行超时的存储过程线程，用 KILL QUERY 终止它（不中断连接）。
- 创建一个监控存储过程，例如
kill_long_running_procedure - 里面用
DECLARE cur1 CURSOR FOR SELECT ID FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND = 'Query' AND TIME > 120 - 循环中对每个匹配的
ID执行KILL QUERY @var_kill_id - 再建一个每 5 秒触发一次的
EVENT，调用这个过程
注意：KILL QUERY 只终止当前正在执行的语句，不会回滚整个存储过程；若过程已进入事务且修改了数据，需自行处理一致性。
更可控的做法：在存储过程中手动埋点检测
如果你能修改存储过程逻辑，最可靠的方式是把超时控制“下沉”到过程内部，用 NOW() 或 SYSDATE() 做时间戳比对：
- 在过程开头记录开始时间：
DECLARE start_ts DATETIME DEFAULT NOW(); - 在关键长耗时操作（如大表遍历、嵌套循环）前后插入判断：
IF TIMESTAMPDIFF(MICROSECOND, start_ts, NOW()) > 10000000 THEN LEAVE main_loop; END IF; - 配合
LEAVE/ITERATE控制流程，提前退出而不是硬等超时
这种方式不依赖外部机制，响应及时，但要求你清楚哪些分支可能耗时，并预留检测点 —— 复杂过程里容易漏掉某些路径。
真正难处理的是那种“黑盒式”调用：你不能改存储过程源码，又必须防止它无限执行。这时候只能靠 EVENT 方案兜底，但要注意 PROCESSLIST 中的 TIME 字段统计的是当前语句持续时间，不是整个存储过程累计时间，所以阈值要设得比预期总耗时更宽松些，避免误杀。
