当前事务锁等待超时时间可通过SHOW VARIABLES LIKE 'innodb_lock_wait_timeout'查看，默认50秒；该值为会话级生效值，全局值需用SELECT @@global.innodb_lock_wait_timeout确认。
查看当前事务锁等待超时时间（innodb_lock_wait_timeout）
MySQL 的事务锁等待超时由系统变量 innodb_lock_wait_timeout 控制，它决定一个事务在等待行锁时最多忍耐多久，超时后抛出 Lock wait timeout exceeded 错误。这个值默认是 50 秒，但生产环境常需调整。
查法很简单，直接执行：
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
注意：该变量是会话级 + 全局级双作用域的，所以你看到的结果是当前会话生效值；若要确认全局设定，加 GLOBAL 修饰：
SELECT @@global.innodb_lock_wait_timeout;
常见误区是只查会话值却误以为改了全局 —— 实际上新连接仍用原全局值，除非显式设全局或改配置文件。
安全修改超时时间的三种方式及适用场景
修改必须区分「临时生效」和「持久生效」，且不能无脑调大。过长的等待会堆积阻塞、拖垮连接池；过短又容易误杀正当等待。
-
仅当前会话生效（最安全，推荐调试用）：
SET innodb_lock_wait_timeout = 120;
这不会影响其他连接，断开重连即失效，适合排查某条 SQL 的锁等待行为。 -
全局动态修改（重启前有效，需权限）：
SET GLOBAL innodb_lock_wait_timeout = 60;
所有后续新连接都会继承该值，但已存在的会话不受影响。需要SUPER或SYSTEM_VARIABLES_ADMIN权限。 -
永久生效（必须改配置文件）： 在
my.cnf或my.ini的[mysqld]段下添加：innodb_lock_wait_timeout = 30
修改后需重启 MySQL 实例才生效。这是唯一能确保每次启动都一致的方式。
修改后验证是否真正生效
很多人设完 GLOBAL 就以为万事大吉，结果应用还是报 50 秒超时 —— 很可能因为应用连接复用旧会话，或框架（如 Spring Boot）在连接初始化时显式设置了会话级变量覆盖了全局值。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
验证建议分两步：
- 新开一个客户端连接，执行
SELECT @@innodb_lock_wait_timeout;
确认返回值是你设的数字； - 在应用侧触发一次典型写事务（比如更新同一行），用
SHOW ENGINE INNODB STATUS\G查看TRANSACTIONS部分，观察实际等待是否按新阈值中断。
特别注意：某些 ORM（如 Hibernate）或连接池（如 HikariCP）会在获取连接后自动执行 SET SESSION innodb_lock_wait_timeout = ...，此时即使你改了全局也没用 —— 得去查它们的配置项（例如 HikariCP 的 connection-init-sql）。
为什么不能随便设成 0 或极大值？
innodb_lock_wait_timeout 不支持设为 0（会报错 Variable 'innodb_lock_wait_timeout' can't be set to the value of '0'），最小合法值是 1。设成极大值（如 86400）看似“保险”，实则危险：
- 一个死锁或长期持有锁的事务，会让所有等待者挂住一整天，快速耗尽
max_connections； - 监控系统（如 Prometheus + mysqld_exporter）依赖超时异常发现阻塞问题，设太大反而掩盖真实瓶颈；
- InnoDB 内部对超时值做了整型截断处理，超过 2147483647（约 68 年）会回绕，行为不可控。
真正该做的是定位锁等待根源：查 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS，看谁在 hold lock、谁在 wait，而不是靠拉长超时来掩盖。
