MySQL存储过程无事务总超时语法，需组合innodb_lock_wait_timeout、wait_timeout参数配置+过程内超时检查+客户端query timeout三层防护。
存储过程里没法直接设“事务总超时”，得靠组合手段
MySQL 存储过程中没有 SET TRANSACTION TIMEOUT 30 这种语法，也没有事务级执行时长硬限制。所谓“超时间隔”必须拆解为锁等待控制 + 客户端主动中断 + 过程内兜底逻辑三者配合，否则哪怕写个 SLEEP(60) 在事务里，MySQL 也照常挂着连接不释放。
必须改的两个关键参数：innodb_lock_wait_timeout 和 wait_timeout
这两个参数不是可选配置，而是防止存储过程失控的底线：
-
innodb_lock_wait_timeout控制“等锁最多忍多久”，默认 50 秒，建议在会话开头显式设低：SET SESSION innodb_lock_wait_timeout = 15;—— 它只对行锁生效，但能快速暴露争抢问题 -
wait_timeout决定连接空闲多久断开，设太大会让卡在SLEEP或 HTTP 回调里的存储过程一直占着连接；线上推荐SET SESSION wait_timeout = 300;（5 分钟），注意它只在无任何语句执行时倒计时，一旦过程里执行了UPDATE，计时就重置 - 别碰
interactive_timeout：存储过程调用走的是非交互式连接，它压根不生效
存储过程内部要手动加超时检查和回滚兜底
靠 MySQL 自身机制不够，必须在过程逻辑里埋点干预：
- 用
SELECT NOW() INTO @start_time;记录事务起点，后续关键节点用IF TIMESTAMPDIFF(SECOND, @start_time, NOW()) > 30 THEN ROLLBACK; LEAVE proc_label; END IF;主动退出 - 避免在过程里调
SLEEP()、GET_LOCK()或发起外部请求（如sys_exec）——这些操作不触发锁等待，innodb_lock_wait_timeout完全无效 - 所有
START TRANSACTION必须配对COMMIT或ROLLBACK，且包裹在DECLARE EXIT HANDLER FOR SQLEXCEPTION里，否则异常跳出时事务悬空
客户端调用层必须带 context 或 query timeout
存储过程再严谨，也防不住调用方卡死。Java、Python、Go 的驱动都支持语句级中断：
- JDBC：
PreparedStatement.setQueryTimeout(30)，超时后触发SQLException并自动 close 连接 - Python pymysql：
cursor.execute(sql, timeout=30)，超时抛pymysql.OperationalError - Go database/sql：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)，传给db.QueryContext() - 这个 timeout 是最有效的防线——它能在存储过程内部某条 SQL 卡住时立刻中断，而不是等整个过程跑完才检查
真正容易被忽略的是：innodb_lock_wait_timeout 只管“等锁”，不管“执行慢”；wait_timeout 只管“空闲”，不管“正在跑”。存储过程的超时必须靠这三层叠加，缺一不可。
