调小innodb_lock_wait_timeout不会减少锁等待本身，只加快超时发生；适用于应用能重试或需防连接池阻塞的场景，而非解决锁争用；olap或批量作业应调大；安全修改方式为会话级set session或配置文件永久设置；错误仍出现说明根因未解，需优化索引、拆分事务、控制锁粒度。
调小 innodb_lock_wait_timeout 不会减少锁等待本身，只会让等待超时更快发生——它不解决锁争用，只改变超时行为。
什么时候该调这个参数？
主要用在两类场景：一是应用层能主动重试（比如订单创建失败后提示用户“稍后重试”），二是避免长等待阻塞连接池或拖垮整体响应。它不是给“锁太多”开的药方，而是给“不想等太久”的系统配的止损开关。
- 默认值 50 秒对 Web 请求太长，很多框架超时设在 5–10 秒，不调会导致连接卡住、线程堆积
- 微服务间调用链中，下游 DB 等待过久会把上游也拖死，需要更激进的超时控制
- OLAP 查询或批量导入场景下，反而要调大（比如设为 3600），否则中途被杀导致数据不一致
怎么安全地改？别直接全局 SET
全局动态修改 SET GLOBAL innodb_lock_wait_timeout = 10 立即生效，但风险高：所有会话立刻受新值约束，可能让原本能成功的事务突然失败。更稳妥的做法是按需覆盖：
- 应用连接池初始化时执行
SET SESSION innodb_lock_wait_timeout = 5，只影响当前连接 - 关键业务 SQL 前加
SET innodb_lock_wait_timeout = 3（注意：MySQL 8.0+ 支持 SESSION 级临时设置） - 配置文件里写
innodb_lock_wait_timeout = 10，重启后生效，适合稳定环境统一策略
调了之后为什么还是看到 Lock wait timeout exceeded？
这个错误（ERROR 1205 (HY000): Deadlock found when trying to get lock; try restarting transaction 或 ERROR 1205 实际是死锁，而 Lock wait timeout exceeded 是 ERROR 1205 的常见误读，真实错误码是 ERROR 1205 对应死锁，ERROR 1213 才是锁等待超时）说明你没解决根本问题：
- 事务里混用了
SELECT ... FOR UPDATE和非索引条件更新，导致锁范围过大 - 多个事务以不同顺序访问相同行（比如 A 先更新 user 表再更新 order 表，B 反过来），容易触发死锁而非单纯等待
- 事务没及时提交，比如在事务里调了外部 HTTP 接口，锁持有时间远超预期
真正减少锁等待，得靠代码和索引
参数只是兜底手段。实际压测中发现，90% 的锁等待问题来自这三处：
- UPDATE 语句没走索引 → 加上
EXPLAIN确认执行计划，补上 WHERE 条件对应字段的索引 - 事务跨多个表操作 → 拆成单表事务，用最终一致性代替强一致性（比如发 MQ 更新关联表）
- 批量更新用
IN (id1,id2,...)→ 改成分页循环，每次最多 100 行，降低单次锁粒度
调 innodb_lock_wait_timeout 就像调汽车油门灵敏度——它不能让车不堵，只能决定你踩多久油门后自动熄火。真想少等锁，得去查慢查询日志、看 SHOW ENGINE INNODB STATUS 里的 latest deadlock，再回代码里动刀子。
