最准命令是SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';——查全局当前生效值；SELECT @@innodb_lock_wait_timeout;——查当前会话值；SELECT @@global.innodb_lock_wait_timeout;——查全局基准值。
不能只改这个参数就认为解决了锁问题——它只是报错开关，不是性能解药。
查看当前值用哪条命令
直接查最准，别猜默认值：
-
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';—— 查全局当前生效值 -
SELECT @@innodb_lock_wait_timeout;—— 查当前会话值（可能被 SET SESSION 覆盖） -
SELECT @@global.innodb_lock_wait_timeout;—— 查全局基准值（新连接继承它）
注意：SHOW VARIABLES 返回的是全局值，但如果你之前执行过 SET SESSION，那当前会话实际用的可能是另一个数。
临时改（不重启，立即生效）
适合测试、紧急压测或单次批任务：
- 改当前会话：
SET SESSION innodb_lock_wait_timeout = 15;—— 只影响这条连接，断开就丢 - 改全局（新连接才用）：
SET GLOBAL innodb_lock_wait_timeout = 15;—— 需要SUPER权限，已存在的连接不受影响
常见坑：执行 SET GLOBAL 后立刻查 SHOW VARIABLES 看到值变了，但旧连接仍用老值；误以为“全系统都改了”。
永久改（重启后还在）
编辑 MySQL 配置文件（my.cnf 或 my.ini），在 [mysqld] 段下加一行：
[mysqld] innodb_lock_wait_timeout = 15
然后重启 MySQL 服务。没重启=没生效。别漏掉这步。
关键点：innodb_lock_wait_timeout 是整型，单位秒，最小值是 1，别设成 0（无效）或字符串（报错）。
设多少才算合理
没有万能数字，得看业务类型和响应要求：
- 高并发 OLTP（如电商下单）：
10～25秒 —— 快速失败比让用户等 50 秒强 - 后台报表或 ETL 批处理：
300（5 分钟）甚至1800（30 分钟） —— 避免正常大事务被误杀 - 别设成
3600或更大 —— 这不是延长等待，是把阻塞变成“静默卡死”，监控更难发现
真正该花时间做的，是查 information_schema.INNODB_TRX 和 SHOW ENGINE INNODB STATUS\G，定位谁在 hold 锁、为什么没提交。调参只是兜底，不是根治。
