mysql不支持事务总耗时硬限制，需组合innodb_lock_wait_timeout（控制等锁超时，默认50秒，oltp建议10～25秒）、wait_timeout（控制空闲连接断开，默认28800秒，生产推荐300秒）及客户端query timeout（如jdbc setquerytimeout）三层防护，同时必须在应用层严格管控事务边界、避免非db操作嵌入事务。
MySQL 本身不支持“事务执行总时长超时”这种硬限制，所谓“配置事务超时”实际是组合控制锁等待、连接空闲、应用层中断三类行为——只调一个参数，必然漏防。
innodb_lock_wait_timeout 控制的是“等锁超时”，不是“事务超时”
这个参数决定一个事务在尝试获取行锁失败后，最多等多久就报 Lock wait timeout exceeded 错误。它不终止事务本身，只让当前语句失败并回滚，而事务仍处于活跃状态，继续持有已获得的锁。
- 默认值是 50 秒，线上 OLTP 场景建议设为
10～25；过高会让阻塞持续太久，过低容易把正常竞争误判为超时 - 必须用会话级设置：
SET SESSION innodb_lock_wait_timeout = 15;，全局 SET GLOBAL 不影响已有连接 - 它对
SLEEP()、外部 HTTP 调用、大循环处理等“非锁等待型卡顿”完全无效——这些操作 MySQL 看不到锁争抢，也就不会触发该超时 - 注意：它只管 InnoDB 行锁/页锁，不管 MDL（表级元数据锁），后者由
lock_wait_timeout参数控制，默认 31536000 秒（一年）
wait_timeout 是防连接挂起的关键，但只在“空闲时”倒计时
wait_timeout 决定非交互式连接（如 Java JDBC、Python pymysql）空闲多久被服务端断开。但它不是事务超时开关：只要事务内执行了任意 SQL，倒计时就重置。
- 默认 28800 秒（8 小时），生产环境必须下调，推荐
300（5 分钟） - 修改需写入
my.cnf的[mysqld]段，并重启mysqld才持久生效；临时SET GLOBAL重启即失效 - 它和连接池行为强耦合：若 HikariCP 的
maxLifetime设为 30 分钟，而wait_timeout是 5 分钟，连接大概率在被 MySQL 杀掉前就被池子回收了——所以应让wait_timeout > maxLifetime（例如前者 300，后者 270） - 别碰
interactive_timeout：存储过程调用走非交互式连接，它完全不生效
真正要监控和干预的是“未提交的长事务”，不是“慢查询”
很多挂起事务根本不争锁，只是 BEGIN 了却没 COMMIT/ROLLBACK，比如异常退出、调试忘收尾、或事务里混了 HTTP 请求。这类事务不会触发 innodb_lock_wait_timeout，但会长期持有锁、拖慢 purge、阻塞 DDL。
- 查活跃长事务：
SELECT trx_id, trx_started, trx_state, trx_query FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60; - 结合
PROCESSLIST定位线程：SELECT * FROM information_schema.PROCESSLIST WHERE ID = ?;，看Command是否为Sleep且Time很大 - 禁止在事务内做非 DB 操作；必须做的，拆成“读→提交→处理→再写”两段式
- 所有
START TRANSACTION必须包裹在DECLARE EXIT HANDLER FOR SQLEXCEPTION里，否则异常跳出时事务悬空
客户端 query timeout 是最有效的最后一道防线
服务端参数再严，也防不住调用方卡死。Java、Python、Go 的驱动都支持语句级中断，这是唯一能真正“终止正在运行的存储过程”的机制。
- Java 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 单位是秒（pymysql）或毫秒（JDBC），且必须小于上层 HTTP 接口超时，否则会出现“DB 已断但接口还在等”的级联卡顿
最容易被忽略的点是：事务挂起往往不是配置没设对，而是应用逻辑把耗时操作（如回调、文件 IO、循环计算）塞进了事务边界内——MySQL 不知道你在等什么，它只认 BEGIN 到 COMMIT 的时间跨度。防挂起，本质是把事务控制权从数据库拉回到应用代码里。
