结论是：innodb_lock_wait_timeout只控制等待锁的超时，不解决锁持有过长或SQL执行慢的问题；应先查INNODB_TRX等定位持锁源头，再结合业务场景设合理值（如金融5秒、Web15秒、离线300秒），并确保应用层控制事务边界与连接池协同。
直接说结论：别只调 innodb_lock_wait_timeout，它只管“等锁”，不管“锁太久”或“SQL慢”。真要解决问题，得先定位谁在持锁不放，再配合应用层控制事务边界。
怎么查当前连接实际生效的锁等待超时值
别信配置文件里写的值，也别只看 SHOW VARIABLES——连接池复用的连接可能继承的是建连时的全局默认值，早已和你后来 SET GLOBAL 的值脱节。
- 查当前会话值：
SELECT @@innodb_lock_wait_timeout; - 查所有活跃连接真实值（MySQL 8.0+）：
SELECT THREAD_ID, VARIABLE_VALUE FROM performance_schema.variables_by_thread WHERE VARIABLE_NAME = 'innodb_lock_wait_timeout'; - 如果用的是 HikariCP/Druid/pymysql pool，这个值大概率是连接初始化那一刻从全局继承来的，不是你临时
SET SESSION改的
SET GLOBAL 和 SET SESSION 到底改了谁
这两个命令作用范围完全不同，混淆会导致“以为改了，其实没起效”：
-
SET SESSION innodb_lock_wait_timeout = 5：只改当前连接，适合在支付类关键事务前显式收紧；连接池复用的连接不受影响 -
SET GLOBAL innodb_lock_wait_timeout = 10：只对后续新建的连接生效，已存在的连接（包括连接池里正在复用的）完全不变 - 没有
SUPER权限？那就只能改/etc/my.cnf+ 重启，或退而求其次，在应用层每个事务开头加SET SESSION innodb_lock_wait_timeout = 5
设成多少秒才算合理
不是看“建议值”，而是对齐业务响应边界和重试能力：
- 金融类强一致操作（如扣款）：
innodb_lock_wait_timeout = 5——错误需秒级暴露，留给应用重试窗口 - 普通 Web 业务（如订单创建）：
innodb_lock_wait_timeout = 15——多数正常 DML 应在毫秒级完成，15 秒能覆盖临时抖动 - 离线任务或后台管理：
innodb_lock_wait_timeout = 300——但必须确保事务本身不长期持有锁 - 绝对不要设为 0（无限等待）或 >300（5 分钟以上），前者易引发连接堆积，后者掩盖真实瓶颈
- 设得太小（如 2 秒）容易因网络抖动或 IO 延迟误超时；设太大（如 60 秒）则前端早超时（
nginx proxy_read_timeout=60），后端还在干等，线程池被占满
为什么调了还是报 Lock wait timeout exceeded
这个参数只管「等锁」，不管「锁太久」或「执行慢」：
-
UPDATE ... WHERE unindexed_column = ?这种语句会全表扫描并锁住所有扫描行，导致锁范围失控——不是等锁超时，是“本该锁 1 行，结果锁了 5000 行” - 频繁报错大概率不是超时设得太长，而是锁本身不该被等那么久；优先查
sys.innodb_lock_waits、INNODB_TRX、performance_schema.data_locks定位阻塞源 -
innodb_lock_wait_timeout对已持有锁的事务无效，只影响“正在等锁”的事务；它不解决锁持有过长的根源，比如忘了COMMIT或触发器隐式锁表
最容易被忽略的一点：MySQL 自身无法感知“事务是否该结束”，只能靠应用主动提交/回滚，或连接池定期探活。只调数据库参数，不配连接池的空闲检测和事务超时兜底，问题照样发生。
