innodb_lock_wait_timeout仅设事务等待行锁的硬性超时阈值（默认50秒），不参与锁分配或优先级调度；真正实现动态优先级调度的是MySQL 8.0.3+默认启用的CATS算法，它依据争用热度、等待链长度等实时决策，与该参数无关。
MySQL 8.0 中 innodb_lock_wait_timeout 不是“动态锁优先级调度”的开关，它只是事务等待行锁的硬性超时阈值；真正在做优先级调度的是 CATS（Contention-Aware Transaction Scheduling）算法，而它完全不依赖这个参数。
为什么改 innodb_lock_wait_timeout 不能实现“锁优先级”
这个参数只控制一个事务在请求行锁失败后，最多原地等待多久才报错 ERROR 1205 (HY000): Lock wait timeout exceeded。它不参与锁分配决策，也不影响哪个事务先拿到锁——InnoDB 在 8.0.3+ 默认启用 CATS 算法，由其根据事务争用热度、等待链长度、undo 量等动态决定谁该“插队”或让出资源。
常见误解场景：
- 以为把
innodb_lock_wait_timeout设成 1 秒就能“快速释放低优事务” → 实际只是让失败更快暴露，不改变调度逻辑 - 在高并发更新同一行时调小该值，结果大量
Lock wait timeout报错 → 这是掩盖死锁检测问题，而非优化调度 - 误以为它和
innodb_deadlock_detect是同一类机制 → 后者触发 wait-for graph 检测，前者纯被动计时
真正影响锁调度行为的三个关键点
CATS 算法默认开启（MySQL 8.0.3+），但它的效果受底层配置制约。以下三点比调 innodb_lock_wait_timeout 更直接干预调度质量：
-
innodb_deadlock_detect = ON（必须开）：CATS 依赖 wait-for graph 的实时图结构，关掉就退化为 FIFO 排队 -
innodb_thread_concurrency设为 CPU 核心数或 2 倍（如 64）：过高会导致线程争抢 mutex，干扰 CATS 的竞争感知判断；过低则压不住并发，使调度失去意义 - 避免长事务持有锁：CATS 对“已运行 30 秒且还在更新”的事务天然降权，但若事务本身没提交，
innodb_lock_wait_timeout再小也拦不住它继续占着锁
innodb_lock_wait_timeout 的合理取值策略
它不是调度参数，而是**故障响应兜底参数**。设得太短会误杀正常等待（比如大事务批量更新中间状态），太长会让应用卡住难感知。生产环境建议按业务敏感度分级：
- 金融类强一致性事务：
innodb_lock_wait_timeout = 5（秒）→ 错误需秒级暴露，配合应用层重试 - 普通 Web 业务（如订单、评论）：
innodb_lock_wait_timeout = 30→ 平衡用户体验与后台稳定性 - 离线任务或管理后台：
innodb_lock_wait_timeout = 300→ 避免因临时锁争用中断长流程 - 绝对不要设为 0 或负数：MySQL 会静默转为默认值（8.0 是 31536000），反而失去控制
动态设置示例：SET SESSION innodb_lock_wait_timeout = 30;（仅对当前连接生效）
排查锁调度异常时优先看什么
当发现事务总在“不该等的时候等”或“该等的时候立刻超时”，别急着调 innodb_lock_wait_timeout，先确认：
- 是否真有锁冲突？查
SELECT * FROM performance_schema.data_locks和data_lock_waits - CATS 是否生效？执行
SELECT @@innodb_deadlock_detect, @@version，版本低于 8.0.3 则无 CATS - 有没有事务忘记提交？用
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING'找长时间 RUNNING 的事务 - 锁等待是否集中在某张表/某几行？用
SELECT * FROM performance_schema.table_handles结合data_locks定位热点
真正复杂的点在于：CATS 的调度决策不可见、不可配置，只能通过 innodb_deadlock_detect 开关和系统负载间接影响。与其纠结超时值，不如把锁粒度（索引设计）、事务边界（尽早提交）、热点拆分（分表/缓存）做扎实。
