mysql 5.7 中 max_execution_time 对存储过程无效，因其仅作用于顶层只读 select；需结合 processlist 主动监控杀 query、过程内时间埋点、performance_schema 深度分析三者协同。
MySQL 5.7 中无法用 max_execution_time 限制存储过程执行时长，必须靠主动监控 + 杀查询 + 过程内埋点三者配合，缺一不可。
为什么 SET SESSION max_execution_time 在存储过程中完全无效
这不是配置遗漏或权限问题，而是 MySQL 的硬性设计：该参数只对顶层、独立、只读的 SELECT 生效。存储过程内所有语句（包括 SELECT SLEEP(60)）都属于子执行单元（substatement），直接绕过超时检查路径。官方文档明确写有：max_execution_time is ignored for SELECT statements in stored programs。你在过程开头写 SET SESSION max_execution_time = 1000，等于没写。
用 INFORMATION_SCHEMA.PROCESSLIST 主动扫描并 KILL QUERY
这是最通用、不依赖外部工具的落地方式，适合封装成监控过程：
- 筛选条件要精准：
COMMAND = 'Execute'（不是Query），STATE != 'Sleep'，TIME > 120（单位秒），INFO LIKE 'CALL %' - 务必用
KILL QUERY @id，不是KILL @id—— 后者会断开整个连接，可能中断其他正常事务 - 注意
INFO字段可能被截断为NULL，此时该行已无参考价值，需转向performance_schema - 若过程已修改数据且未提交，
KILL QUERY只终止当前语句，不会回滚事务，后续需靠幂等逻辑或标记表兜底
在存储过程中手动埋点检测时间
如果你能改源码，这是最轻量、最可控的方式：
- 开头声明：
DECLARE start_ts DATETIME DEFAULT NOW(); - 在循环、大查询或关键节点前插入判断：
IF TIMESTAMPDIFF(MICROSECOND, start_ts, NOW()) > 10000000 THEN LEAVE proc_label; END IF;（10 秒阈值） - 避免用
NOW()频繁调用，可改用UNIX_TIMESTAMP()减少开销 - 该方式不依赖外部状态，但无法覆盖已部署且不可修改的过程
用 performance_schema 深挖 CALL 内部耗时
当 PROCESSLIST 只显示 “正在执行”，却找不到瓶颈时，必须进 performance_schema：
- 先查入口：
SELECT THREAD_ID, SQL_TEXT FROM performance_schema.events_statements_current WHERE EVENT_NAME = 'statement/sql/call' - 确认启用：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'statement/sql/call'; - 顺着
THREAD_ID查历史：SELECT SQL_TEXT, TIMER_WAIT/1000000000000 AS sec, ROWS_EXAMINED FROM performance_schema.events_statements_history_long WHERE THREAD_ID = ? ORDER BY TIMER_START DESC LIMIT 10 -
TIMER_WAIT单位是皮秒，不除以1000000000000就是一串不可读数字
真正难处理的不是“怎么杀”，而是“杀完之后事务状态是否一致”——尤其当过程跨多表更新、含临时表或游标时，KILL QUERY 可能留下部分生效、部分回滚的中间态。埋点退出虽安全，但需要提前规划；而 performance_schema 分析虽准，但默认常被禁用且消耗额外资源。三者得按场景组合用，不能只押一种。
