innodb_lock_wait_timeout不是“设多大”的问题，而是“谁该等、等多久、等了之后怎么办”链条中的一环；设错值只改变失败暴露快慢，不解决锁持有过长根源，频繁超时主因是长事务未提交、缺失索引致全表扫描、事务混入非DB操作或间隙锁范围过大。
直接说结论：innodb_lock_wait_timeout 不是“该设多大”的问题，而是“谁该等、等多久、等了之后怎么办”这个链条里的一环。设错值不会解决问题，只会让失败更快或更慢地暴露出来。
为什么改了 innodb_lock_wait_timeout 还是报 Lock wait timeout
这个参数只控制「等待锁」的时间上限，不解决「为什么别人不放锁」。频繁报 Lock wait timeout exceeded; try restarting transaction，大概率是以下情况之一：
- 有长事务没提交：用
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - TRX_STARTED) > 60查运行超 1 分钟的事务 - UPDATE/DELETE 没走索引，导致全表扫描并升级为间隙锁甚至表级争抢
- 事务里混了 HTTP 调用、sleep、文件读写等非数据库操作，锁持有时间不可控
- 隔离级别是
REPEATABLE-READ且做了范围条件更新，间隙锁范围过大
innodb_lock_wait_timeout 的合理取值范围
没有万能值，必须按业务场景分级定，且要和应用层超时对齐：
- 金融类强一致性操作（如支付扣款）：
5秒 —— 错误需秒级暴露，留给重试或降级的时间窗口更宽 - 普通 Web 业务（订单创建、评论提交）：
15秒 —— 多数正常 DML 应在毫秒级完成，15 秒已足够覆盖网络抖动和临时 IO 延迟 - 离线任务或管理后台批量更新：
300秒 —— 但必须搭配小事务拆分（如UPDATE ... LIMIT 1000+ 显式COMMIT），不能靠拉长等待硬扛
绝对不要设为 0（无限等待）或超过 300（5 分钟）——前者会让连接永远挂起，后者让前端早超时了，后端还在干等。
全局设置 vs 会话设置，哪个更实用
生产环境推荐组合使用，而不是二选一：
- 基础兜底值写进配置文件：
[mysqld]段加innodb_lock_wait_timeout = 15，重启后永久生效 - 关键业务连接池初始化时执行：
SET SESSION innodb_lock_wait_timeout = 5，显式收紧，避免被 ORM 连接复用绕过 - 避免在 SQL 中动态
SET—— 难审计、易遗漏、无法保证每次执行都命中
注意：SET GLOBAL innodb_lock_wait_timeout = 15 只对新建立的连接生效，已连上的旧连接仍用原值；线上服务 reload 配置也不会触发重连，所以你以为改了，其实没起效。
最容易被忽略的配套动作
单调这个参数，99% 是白忙。真正起作用的是下面这几件事：
- 必须开启
innodb_rollback_on_timeout = ON（MySQL 5.7+ 默认开启），否则超时后事务不会自动回滚，留下半开状态 - 把
Innodb_row_lock_waits和Innodb_row_lock_time_avg加入监控，比盯错误日志更有预见性 - 查锁链路别只看
SHOW PROCESSLIST，要用INFORMATION_SCHEMA.INNODB_TRX+INNODB_LOCK_WAITS关联定位持锁源头 - 所有
SELECT ... FOR UPDATE必须确保 WHERE 条件命中**最左匹配的唯一索引**，否则可能锁住整个索引范围
锁超时本质是资源竞争暴露出来的症状，innodb_lock_wait_timeout 只是调节痛感的刻度盘；真正要盯紧的，是哪些 SQL 在抢同一行、哪个服务迟迟不提交、索引是否覆盖了所有高频更新路径。
