控制mysql事务锁等待超时的参数是innodb_lock_wait_timeout，默认50秒，影响insert/update/delete等行锁等待行为，不控制死锁检测；需结合连接池、jdbc sockettimeout及应用重试协同调优。
MySQL 事务锁等待超时由哪个参数控制
根本不是 wait_timeout 或 interactive_timeout——这两个只管连接空闲多久断开，跟事务内部锁等待完全无关。真正起作用的是 innodb_lock_wait_timeout，它定义了事务在等待行锁（比如被另一个事务占着的记录）时最多忍几秒。
- 默认值是 50 秒，对多数 OLTP 场景偏长，网络抖动或慢查询偶发时容易让应用线程卡住不动
- 该参数可全局设置，也能在会话级临时调整：
SET SESSION innodb_lock_wait_timeout = 5; - 注意：它只影响
INSERT/UPDATE/DELETE等需要加行锁的操作，不影响SELECT ... FOR UPDATE的锁获取逻辑本身，但影响其等待行为
为什么不能直接设成 1 秒甚至更低
太激进会把本可成功的短等待变成 Lock wait timeout exceeded 错误，尤其在高并发更新同一张表热点行时。这不是“防住问题”，而是把问题从“延迟大”转成了“失败多”。
- 典型场景：秒杀库存扣减、订单状态机流转——这些操作本身快，但竞争激烈，合理值在 3–10 秒之间更稳妥
-
innodb_lock_wait_timeout不影响死锁检测，死锁仍会在 10 秒左右被自动回滚（由innodb_deadlock_detect和内部机制决定） - 若业务能容忍部分失败并重试，设低些没问题；若要求强一致性且重试成本高，建议配合应用层超时（如 JDBC 的
socketTimeout）做双重防护
如何验证当前锁等待是否真由网络延迟引发
别猜。先看 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS，确认是不是真有事务卡在锁等待，再结合网络指标交叉判断。
- 查正在等待锁的事务：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT'; - 查谁在等、等谁：
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; - 如果发现
TRX_WAIT_STARTED时间戳比应用日志里的请求发起时间晚几百毫秒以上，且 DB 服务器 CPU、磁盘 I/O 正常，那大概率是客户端到 DB 的网络延迟叠加了锁等待，而非 MySQL 自身慢
应用侧配合：JDBC 连接池与语句超时不能只靠 MySQL 配置
MySQL 层的 innodb_lock_wait_timeout 是最后一道防线。前面还有两层必须设好，否则照样挂住线程。
- 连接池（如 HikariCP）要配
connection-timeout（获取连接超时）和validation-timeout，避免拿不到连接就干等 - JDBC URL 加
socketTimeout=3000（单位毫秒），防止网络卡死导致 TCP 连接无限 hang 住 - 执行语句时显式设超时：
PreparedStatement.setQueryTimeout(5)，这个值应 ≤innodb_lock_wait_timeout，否则 MySQL 还没触发超时，应用侧已抛异常
实际调参时，得把数据库配置、连接池、JDBC 层、应用重试逻辑串起来看。单独改一个地方，往往只是把问题推到下一层。
