innodb_lock_wait_timeout是MySQL中唯一控制事务等待InnoDB行锁时长的参数，仅对UPDATE/DELETE/SELECT FOR UPDATE等加锁操作生效，默认50秒；它不干预死锁检测、连接空闲或SQL执行超时，设为15秒适用于OLTP订单支付场景，需配合查长事务、补索引和拆事务根治锁争抢。
innodb_lock_wait_timeout 是唯一生效的锁等待超时参数
MySQL 中真正控制事务等待行锁时长的，只有 innodb_lock_wait_timeout。它不叫“事务超时”，也不管连接空闲、SQL执行时长或死锁检测——只管一件事：当前事务在本实例内，为获取某行锁（比如被另一个事务占着的记录）最多愿意等几秒。默认值是 50 秒，线上多数 OLTP 场景偏长，容易让一个卡住的请求拖住整个线程池。
其他名字相似的参数全是干扰项：wait_timeout 和 interactive_timeout 控制连接空闲断开，跟锁无关；max_execution_time 只限制单条 SELECT 的执行时长；lock_wait_timeout 是 Server 层参数，对 InnoDB 行锁无效。
-
innodb_lock_wait_timeout是会话级变量，可动态改，不影响已有连接 - 它只作用于
INSERT/UPDATE/DELETE和SELECT ... FOR UPDATE等需要加锁的操作 - 超时后报错，错误码固定为
ERROR 1205 (40001)，但需结合SHOW ENGINE INNODB STATUS判断是真死锁还是纯等待超时
设成多少秒才算合理？看业务类型和重试能力
不是越小越好，也不是越大越稳。1 秒会导致热点行更新频繁失败；300 秒会让用户等五分钟才看到错误，体验更差。关键在平衡。
- 普通订单/支付类接口：建议设为
15秒——足够覆盖网络抖动和轻量锁争抢，又不至于让单个卡顿拖垮接口 - 已接入 Spring Retry + 幂等逻辑的服务：可放宽到
25秒，给重试留出缓冲 - 秒杀类库存扣减：竞争激烈但逻辑极简，设
5～10秒更合适 - 绝对不要设为
0（无限等待）或超过60秒，这等于主动放弃故障隔离
怎么改？三类方式适用场景完全不同
改参数本身很简单，但生效范围和持久性差异极大，选错方式等于白调。
- 临时调试单条 SQL：运行
SET SESSION innodb_lock_wait_timeout = 10;，仅当前会话生效 - 灰度上线新策略：用
SET GLOBAL innodb_lock_wait_timeout = 15;，新建立的连接立即生效，旧连接仍用旧值，需等连接池自然回收 - 长期稳定配置：写进
/etc/my.cnf的[mysqld]段，加一行innodb_lock_wait_timeout = 15，重启 MySQL 或用SET GLOBAL同步，否则配置文件不会自动加载
注意：SET GLOBAL 需要 SUPER 权限，且修改后必须确认应用连接池已重建连接，否则监控里看到的仍是旧值。
比调参更重要的三件事：锁卡死 rarely 是超时没设好
把 innodb_lock_wait_timeout 从 50 改成 15，只是让报错快一点。真正导致“系统卡死”的，往往是下面这些被忽略的根因：
- 事务里夹了 HTTP 调用、文件读写或循环计算——MySQL 不知道你在等外部服务，它只认
BEGIN到COMMIT的时长 - 缺失索引导致全表扫描+锁升级，让一个
UPDATE持锁几十秒 - 连接池未配
connection-timeout，应用连不上 DB 时干等，看起来像“锁卡住”
先跑一次 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT';，再对照应用日志看 TRX_WAIT_STARTED 时间戳——如果比请求发起晚几百毫秒以上，问题大概率出在网络或应用层，而不是 MySQL 锁参数本身。
