innodb_lock_wait_timeout控制事务等待行锁的最长时间，超时即报错回滚，不解决锁持有过长根源；默认50秒偏长，oltp场景建议10～30秒，需与应用层超时及连接池配置对齐。
innodb_lock_wait_timeout 控制事务锁等待超时
这个参数决定一个事务在等待行锁时最多能等多久，超时后直接报错回滚，而不是无限卡住。它不控制连接空闲时间，只管“抢不到锁”这一环节。
常见错误现象是应用日志里反复出现 Lock wait timeout exceeded; try restarting transaction，尤其在高并发更新同一行数据时。
使用场景包括：防止长事务阻塞其他操作、避免因前端用户长时间不提交导致后台锁堆积。
- 默认值是
50秒，对大多数 OLTP 场景偏长；可设为10～30秒更稳妥 - 动态设置立即生效：
SET GLOBAL innodb_lock_wait_timeout = 20; - 持久化需写入
/etc/my.cnf的[mysqld]段：innodb_lock_wait_timeout = 20 - 注意：该值对已持有锁的事务无效，只影响“正在等锁”的事务
wait_timeout 和 interactive_timeout 不等于事务超时
这两个参数控制的是连接空闲多久后被 MySQL 主动断开，和事务本身是否完成无关。很多开发者误以为调大它们就能“防事务超时”，其实只是延缓了连接断开，事务仍可能卡死或报错。
典型混淆场景：Java 应用用 HikariCP 连接池，设置了 connection-timeout=30000，但没配 idle-timeout 或 max-lifetime，结果连接池长期复用一个空闲连接，MySQL 在 wait_timeout（默认 28800 秒，即 8 小时）后断开，应用拿到的是“假活跃连接”，抛出 MySQL has gone away。
-
wait_timeout适用于 JDBC 等非交互式连接，建议设为3600（1 小时）或更低 -
interactive_timeout适用于 mysql 客户端等交互式连接，可略高，如28800 - 必须同时改两个，否则只改一个可能不起作用
- 配置后务必重启 MySQL 或执行
SET PERSIST（需有权限），仅SET GLOBAL重启即失效
应用层必须配合连接池的空闲检测
MySQL 自身无法感知“事务是否该结束”，只能靠应用主动提交/回滚，或连接池定期探活。如果只调数据库参数，不配连接池，事务超时问题照样发生。
以 HikariCP 为例，关键三项不能缺：
-
idle-timeout：空闲连接最大存活时间，建议设为比wait_timeout小 1～2 分钟（如 MySQL 设 3600，则这里设 3500） -
max-lifetime：连接最大总寿命，建议设为 1800000（30 分钟），强制轮换，防连接老化 -
connection-test-query（MySQL 8.0.22+ 推荐用connection-init-sql=SELECT 1）：每次从池取连接前执行简单语句验证有效性
DBCP2 或 Druid 同理，testWhileIdle + timeBetweenEvictionRunsMillis 必须打开，且间隔要短于 wait_timeout。
不要依赖 autoReconnect=true
这个 JDBC 参数看似能“自动续命”，但 MySQL 官方明确不推荐。它会在连接断开后新建一个连接，但原事务状态全部丢失——未提交的数据回滚、会话变量清空、预编译语句失效、锁被释放，应用层根本无法感知这些副作用。
真实后果包括：
- 业务逻辑中“先查再更新”的判断失效（查的是旧连接，更新发到新连接）
- 分布式事务上下文断裂（如 Seata、XA）
- 重复插入或更新丢失（因为重连后重试，而原事务其实已部分执行）
正确做法是：用连接池健康检查 + 应用层幂等设计，而不是把问题甩给驱动层。
真正复杂的点不在参数数字本身，而在数据库、连接池、应用事务边界的对齐。少设一个 idle-timeout，就可能让 innodb_lock_wait_timeout 彻底失效。
