max_execution_time对存储过程完全无效——因其仅作用于独立只读SELECT语句，存储过程内所有语句属子执行单元，绕过超时检查；替代方案包括EVENT轮询PROCESSLIST主动KILL QUERY，或在过程内手动埋点检测时间并LEAVE退出。
max_execution_time 对存储过程完全无效
MySQL 官方明确声明：max_execution_time 参数只作用于「独立执行的只读 SELECT 语句」，对存储过程内的任何语句（包括 SELECT、INSERT、循环、函数调用）全部忽略。哪怕你在过程开头写 SET SESSION max_execution_time = 1000，或在过程内加 /*+ MAX_EXECUTION_TIME(1000) */ hint，都起不到中断效果。
根本原因是执行上下文不同：超时检查只在顶层语句解析阶段触发，而存储过程内部属于子执行单元（substatement），不进入该检查路径。这不是配置错误，也不是权限问题，而是设计如此。
替代方案一：用 EVENT + PROCESSLIST 主动杀查询
既然服务端不提供原生支持，就得靠外部轮询干预。核心思路是定期扫描 INFORMATION_SCHEMA.PROCESSLIST，识别运行超时的存储过程线程并用 KILL QUERY 终止。
- 创建监控过程，例如
kill_long_running_procedure，用CURSOR查询COMMAND = 'Query'且TIME > 120的线程 ID - 对每个匹配 ID 执行
KILL QUERY @id（注意不是KILL CONNECTION，避免断开整个连接） - 再建一个每 5 秒触发一次的
EVENT，调用该过程
注意：KILL QUERY 只终止当前正在执行的语句，不会回滚整个事务；若过程已修改数据且处于事务中，需自行处理一致性。
替代方案二：在存储过程中手动埋点检测
如果你能修改存储过程逻辑，这是最可控的方式——把超时控制“下沉”到过程内部，用时间戳比对实现主动退出。
- 过程开头记录起始时间：
DECLARE start_ts DATETIME DEFAULT NOW(); - 在关键长耗时操作前后插入判断，例如大表遍历或嵌套循环里：
IF TIMESTAMPDIFF(MICROSECOND, start_ts, NOW()) > 10000000 THEN LEAVE main_loop; END IF;（10 秒） - 配合
main_loop:标签和LEAVE/ITERATE控制流程，提前退出而非硬等
这种方式不依赖外部机制，也不受 MySQL 版本或权限限制，但需要你清楚哪些步骤可能耗时，并预留检查点。
容易被忽略的关键细节
innodb_lock_wait_timeout 不是执行超时，它只管「锁等待」，不是「语句执行」；wait_timeout 和 interactive_timeout 管的是空闲连接，对正在跑的存储过程毫无影响；innodb_query_timeout 是个伪参数，MySQL 8.0 中已移除，文档和部分旧资料仍提它，实际不生效。
