合理值为10～30秒，高并发写入场景建议从15秒起步，需结合Innodb_row_lock_time_avg和锁等待次数动态调整，该参数仅控制行锁等待超时，不控制事务总时长或死锁。
innodb_lock_wait_timeout 设置多少才合理
这个参数不是越大越好，也不是越小越安全。它只控制「行锁等待超时」，和事务总时长无关，很多人误以为设大点能避免死锁或长事务失败，其实它只在两个事务争抢同一行锁时起作用——比如事务A更新了某行没提交，事务B也去更新同一行，B就会卡住，直到超过 innodb_lock_wait_timeout 后报错 Lock wait timeout exceeded。
默认值是 50 秒，线上业务常见设为 10～30 秒。设太小（如 1 秒）会导致正常短等待也被中断，增加应用层重试压力；设太大（如 300 秒）会让阻塞问题隐蔽化，DBA 很难第一时间发现锁冲突源头。
- 高并发写入密集场景（如订单扣减），建议从 15 秒起步，观察监控中
Innodb_row_lock_time_avg和超时报错频率再调 - OLAP 类长查询+写入混合场景，需确认是否真有行锁竞争，否则调大无意义，反而掩盖应用逻辑缺陷
- 不能替代应用层的锁重试或乐观锁设计，它只是兜底机制
修改后要不要重启 MySQL
不需要重启，innodb_lock_wait_timeout 是动态参数，运行时就能生效。
- 会话级修改：执行
SET SESSION innodb_lock_wait_timeout = 20;，只影响当前连接 - 全局级修改：执行
SET GLOBAL innodb_lock_wait_timeout = 20;，新建立的连接生效，已存在的连接仍用旧值 - 要持久化，必须写进配置文件
my.cnf的[mysqld]段里，否则重启后恢复默认
为什么改了参数还是报超时
大概率不是这个参数的问题。常见混淆点：
-
innodb_lock_wait_timeout不控制事务自动回滚，也不影响wait_timeout（连接空闲超时）或max_execution_time（语句执行时间限制） - 如果看到的是
ERROR 1205 (40001): Deadlock found when trying to get lock，那是死锁检测机制主动杀掉事务，和该参数无关 - 应用端设置了 JDBC 的
socketTimeout或queryTimeout，网络层先超时断开，MySQL 还没来得及抛出锁等待错误 - 使用了
SELECT ... FOR UPDATE但没走索引，导致锁住整张表或多个间隙，等待范围远超预期
配合哪些指标一起看才有效
单看一个参数没意义，得结合状态变量交叉验证：
- 查当前锁等待情况：
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT'; - 看历史锁平均等待时长：
SHOW STATUS LIKE 'Innodb_row_lock_time_avg';（单位毫秒） - 查最近一小时锁等待次数：
SHOW STATUS LIKE 'Innodb_row_lock_waits'; - 配合慢日志分析是否真有未提交事务长期持有锁，而不是参数本身不够用
真正难处理的从来不是调参，而是定位哪个应用连接、哪条 SQL、在什么数据分布下持续不提交——参数只是把问题暴露得更早一点而已。
