如何通过调整innodb_lock_wait_timeout参数优化MySQL在高并发环境下的锁竞争问题？

本文共计1307个文字，预计阅读时间需要6分钟。

无法。它只控制单个语句等待锁的最长时间（默认+50%秒），超过时间后抛出+ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction。但已有不少锁的保持时间，也不降低锁冲突的概率。调小只会让失败更快暴露，掩盖真实瓶颈——例如长事务未提交、索引缺失导致全表扫描加锁、或隔离级别过高引发悲观锁泛滥。

常见误操作是把 innodb_lock_wait_timeout 改成 5 秒甚至 1 秒，结果线上报错飙升，而锁等待的根因一点没变。

• SET innodb_lock_wait_timeout = 5 仅对当前会话生效；SET GLOBAL innodb_lock_wait_timeout = 5 对新连接生效，已存在的连接不受影响
• 该参数单位是秒，最小可设为 1，但生产环境不建议低于 10 秒——否则网络抖动或临时 IO 延迟都可能触发误超时
• 真正要压降锁竞争，得从锁“谁在持”“持多久”“为什么持”入手，而不是改这个超时开关

怎么快速定位正在持锁和等锁的事务

先查活跃事务，再关联锁等待链，这是诊断的第一步。别一上来就 kill 或调参。

执行：SELECT * FROM information_schema.INNODB_TRX 查看当前所有事务，重点关注 TRX_STATE（是否 RUNNING）、TRX_STARTED（持续时间）、TRX_QUERY（正在执行的 SQL）。