MySQL无事务总耗时超时机制，需组合配置innodb_lock_wait_timeout（锁等待）、wait_timeout（连接空闲）及客户端query timeout（执行层中断）三层防线，缺一不可。
MySQL 本身没有“事务总耗时超时”机制，所谓“设置事务超时”实际是组合控制锁等待、连接空闲和客户端执行三类超时，缺一不可。
innodb_lock_wait_timeout 控制的是锁等待，不是事务执行
这个参数决定事务在尝试获取行锁时最多等多久，超时后报错 Lock wait timeout exceeded，而不是自动回滚整个事务。它只对行锁生效，对 SLEEP()、外部 HTTP 调用、存储过程内循环等完全无效。
- 默认值是
50秒，高并发 OLTP 场景建议设为10～25 - 会话级修改：执行
SET SESSION innodb_lock_wait_timeout = 15;即刻生效 - 全局修改需写入配置文件
[mysqld]段并重启，或用SET GLOBAL innodb_lock_wait_timeout = 15;（注意权限与持久性） - 它不解决死锁，也不限制事务已持有锁后的运行时间——一个事务 BEGIN 后执行
UPDATE再SLEEP(300)，照样卡住 5 分钟不报错
wait_timeout 只管连接空闲，不管事务是否提交
wait_timeout 控制非交互式连接（如 JDBC）在无任何语句执行时的空闲时长。一旦事务里执行了 SELECT 或 UPDATE，倒计时就重置。它无法终止正在运行的事务，但能防止连接长期挂起占用 max_connections。
- 默认
28800秒（8 小时），生产环境应设为300（5 分钟） - 必须配合应用层连接池的
maxLifetime使用，例如 HikariCP 设maxLifetime=270000（4.5 分钟） -
interactive_timeout对存储过程调用无效，因为它是非交互式连接 - 设得太小（如
30）会导致正常长查询被断连，报错MySQL server has gone away
真正防长事务得靠应用层 query timeout + 过程内兜底
MySQL 不提供事务级计时器，唯一可靠的方式是让客户端在 SQL 执行层主动中断。存储过程内部也需手动检查时间戳并 ROLLBACK。
- JDBC：用
PreparedStatement.setQueryTimeout(30)，单位秒，超时抛SQLException - Python pymysql：
cursor.execute(sql, timeout=30) - Go：
db.QueryContext(ctx, sql)配合context.WithTimeout - 存储过程中可记录起点：
SELECT NOW() INTO @start_time;，后续用IF TIMESTAMPDIFF(SECOND, @start_time, NOW()) > 30 THEN ROLLBACK; LEAVE proc_label; END IF; - 所有
START TRANSACTION必须配对COMMIT或ROLLBACK，且包裹在DECLARE EXIT HANDLER FOR SQLEXCEPTION中
最容易被忽略的隐式长事务陷阱
监控 information_schema.INNODB_TRX 表时，很多人只看 trx_state = 'RUNNING'，却漏掉 trx_state = 'LOCK WAIT' 或长时间 'ACTIVE' 但无实际 SQL 执行的状态。这类事务不争锁，却持续阻塞 purge 线程、拖慢 MVCC 清理、阻碍 DDL。
- 查空闲超时事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 300; - 关联
PROCESSLIST查线程状态：SELECT * FROM information_schema.PROCESSLIST WHERE ID = ?; - 避免在事务中调用
GET_LOCK()、SLEEP()或发起网络请求——这些操作绕过所有 MySQL 内部超时机制
真正有效的“事务超时”，是三层防线：客户端 query timeout 主动斩断、innodb_lock_wait_timeout 快速暴露锁争抢、应用逻辑内手动时间检查兜底。单靠改服务端参数，只是把问题从日志里藏得更深一点。
