查看当前行锁等待超时时间用变量 innodb_lock_wait_timeout；执行 SHOW VARIABLES LIKE 'innodb_lock_wait_timeout' 可查会话值，加 GLOBAL 修饰查全局默认值。
查看当前行锁等待超时时间用哪个变量？
MySQL 中控制「事务等待行锁释放」的超时时间，由系统变量 innodb_lock_wait_timeout 决定。它不是全局锁或表锁的超时参数，专指 InnoDB 在执行 UPDATE、DELETE 或带 FOR UPDATE 的 SELECT 时，因无法立即获得行锁而进入等待状态的最大秒数。
查看当前值只需一条命令：
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
注意：这个变量是会话级可覆盖的，所以你看到的可能是全局值，也可能是当前会话已手动改过的值。要确认全局默认值，加 GLOBAL 修饰：
SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait_timeout';
动态修改超时时间会影响哪些连接？
修改 innodb_lock_wait_timeout 分两种作用域，行为完全不同：
-
仅修改当前会话：
SET innodb_lock_wait_timeout = 120;—— 只影响当前连接后续的锁等待，不影响其他连接，也不持久 -
修改全局默认值：
SET GLOBAL innodb_lock_wait_timeout = 120;—— 新建连接将继承该值，但已有连接仍保持自己原来的设置（包括初始连接时继承的老全局值）
也就是说，改了 GLOBAL 并不会“热更新”所有活跃事务的等待逻辑。如果线上有长事务正在等锁，它的超时上限不会因此改变。
另外，该变量不能设为 0（MySQL 8.0.19+ 允许设为 0 表示无限等待，但极不推荐；旧版本设 0 会被自动转为 50），最小合法值通常是 1，最大建议不超过 300（避免拖垮连接池）。
为什么改了超时时间却没看到锁等待报错变快？
常见误解是：调小 innodb_lock_wait_timeout 就能立刻让卡住的语句更快失败。实际上，这个变量只在「新发起锁请求时」生效。以下情况不会触发重评估：
- 事务已处于锁等待中（例如一个
UPDATE卡在 waiting for lock 状态），此时修改变量对它无效 - 使用了
LOCK IN SHARE MODE或FOR UPDATE但尚未真正触发行锁冲突（比如 WHERE 条件没命中索引，走了全表扫描，实际锁的是多个间隙，而非单行） - 底层不是 InnoDB 引擎（如 MyISAM 表无行锁概念，该变量完全不生效）
验证是否真正在等行锁，可查 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS：
SELECT trx_id, trx_mysql_thread_id, trx_query FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT';
再关联 INNODB_LOCK_WAITS 看阻塞链。只有明确出现在这里的等待，才受 innodb_lock_wait_timeout 约束。
生产环境修改前必须确认的三件事
直接执行 SET GLOBAL 看似简单，但容易引发连锁反应：
- 应用层是否有重试逻辑？若把超时从 50 改成 5，可能让原本能等成功的操作频繁抛出
Lock wait timeout exceeded（错误码 1205），而应用没处理这种异常，导致数据不一致 - 监控是否采集了该变量？很多 DBA 监控只拉
GLOBAL值，但业务慢查实际受会话值影响，二者不一致时排查困难 - 是否检查过
innodb_rollback_on_timeout？默认为 OFF，即超时后只回滚当前语句，事务仍开着——这容易造成隐式长事务。建议搭配设为 ON（需重启生效，且影响所有事务）
最稳妥的做法是：先在测试环境模拟锁竞争，观察改值前后应用日志和错误率变化；上线时优先用会话级 SET，按需调整特定 SQL，而不是一刀切改全局。
