innodb_lock_wait_timeout调大只是掩盖锁争用本质问题，真正需优化事务设计、索引缺失、并发逻辑等底层缺陷，否则将加剧阻塞与死锁。
这不是参数设置问题，而是锁争用暴露了底层设计缺陷
为什么调大 innodb_lock_wait_timeout 只是掩耳盗铃
默认 50 秒的超时值本身不是问题，它是 InnoDB 的“安全熔断器”——当一个事务等锁太久，系统主动中断它，防止整个连接池被拖死。你调到 120 秒，错误确实变少了，但用户请求卡在后端的时间从 50 秒变成 120 秒，体验更差；同时，阻塞链更长，死锁概率上升，监控里 INNODB_TRX 中 trx_state = 'LOCK WAIT' 的事务数会持续堆积。
真正该问的是：为什么一个 UPDATE 要等这么久？常见原因有：
- 另一个事务持锁未提交（比如代码里
begin后忘了commit，或异常分支漏处理） -
UPDATE没走索引，触发全表扫描 → 锁住成千上万行 → 别的事务一碰就排队 - 事务内混了 HTTP 调用、文件读写、
SLEEP()等非数据库操作，锁白白挂着 - 高并发下多个事务按不同顺序更新同一组记录（如 A 先更新 user_id=1 再更新 user_id=2，B 反过来），极易形成锁等待链
怎么快速定位谁在“堵路”而不是瞎调参
别等报错才查，出问题前就该跑这三条语句抓快照（注意：锁状态稍纵即逝，必须立刻执行）：
SELECT trx_id, trx_mysql_thread_id, trx_state, trx_started, trx_query FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'LOCK WAIT' ORDER BY trx_started;
找到 waiting_trx_id 后，立刻联查阻塞源：
SELECT r.trx_id waiting_trx_id, r.trx_query waiting_query,
b.trx_id blocking_trx_id, b.trx_query blocking_query
FROM INFORMATION_SCHEMA.INNODB_TRX r
INNER JOIN INFORMATION_SCHEMA.INNODB_LOCK_WAITS w ON r.trx_id = w.requesting_trx_id
INNER JOIN INFORMATION_SCHEMA.INNODB_TRX b ON b.trx_id = w.blocking_trx_id;
再用 blocking_thread 去 PROCESSLIST 查具体 SQL：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE ID = ?;
如果看到 INFO 是空的、COMMAND 是 Sleep、但 TRX_STATE 还是 ACTIVE，基本就是应用端没关事务。
哪些场景下可以谨慎调这个参数
调参不是禁忌，但必须有明确边界和配套动作：
-
SET innodb_lock_wait_timeout = 10用于核心 API 接口（让失败更快暴露，前端可降级） -
SET innodb_lock_wait_timeout = 120仅限后台离线批处理，且必须确保事务内无外部依赖（比如不能调第三方 HTTP） - 用
SET GLOBAL修改后，已建立的连接不会生效 —— 这点线上常踩坑，误以为改了就全局生效 - 永久配置要加进
my.cnf的[mysqld]段，但生产环境重启 MySQL 成本高，不如靠应用层控制
真正该动代码的地方：事务粒度和索引
90% 的锁等待超时，根子在应用逻辑和 SQL 写法上：
- 批量更新不要在一个事务里循环
UPDATE单行，改用INSERT ... ON DUPLICATE KEY UPDATE或分批次提交（每 100 行COMMIT一次） - 所有
WHERE条件字段必须有索引，用EXPLAIN确认type是ref或range，不是ALL - 避免在事务中做
SELECT ... FOR UPDATE后长时间不更新，尤其不要在循环里反复加锁 - 多个服务更新同一张表时，约定统一的加锁顺序（比如总是先按
user_id升序锁，再更新）
锁等待超时从来不是孤立的错误，它是事务设计松散、索引缺失、并发模型粗糙的综合体现。盯着 innodb_lock_wait_timeout 调数字，就像修水管只拧紧漏水的接头，却不管上游水压是否失控。
