MySQL锁等待时间过长本质是事务阻塞或资源争用，需快速定位“谁在等、谁在占、为什么占”：优先查performance_schema.data_lock_waits（8.0+），结合INNODB_TRX、INNODB_LOCK_WAITS和PROCESSLIST定位阻塞源与被阻塞SQL，再分析长事务、无索引扫描、间隙锁、热点行等根因，辅以KILL、超时设置、索引优化及开发规范治理。
MySQL锁等待时间过长，本质是事务阻塞或资源争用导致的，核心思路是：快速定位谁在等、谁在占、为什么占。
查当前锁等待和阻塞关系
优先执行以下语句，直观看到“谁在等谁”：
- SELECT * FROM performance_schema.data_lock_waits;（MySQL 8.0+，最直接）
- SELECT * FROM information_schema.INNODB_TRX; 查活跃事务（trx_state、trx_started、trx_mysql_thread_id）
- SELECT * FROM information_schema.INNODB_LOCKS;（5.7及以前可用，8.0已移除）
- SELECT * FROM information_schema.INNODB_LOCK_WAITS;（关联trx和lock，显示blocking_trx_id和blocked_trx_id）
重点看 blocking_trx_id 对应的事务是否长时间未提交、是否执行了大查询、是否处于sleep状态却没释放锁。
看被阻塞事务在做什么
拿到 blocked_trx_id 后，用线程ID查其SQL：
- SELECT * FROM information_schema.PROCESSLIST WHERE ID = ?;（查看state、info字段）
- 若 info 为空，可能是空闲连接；若 state 是 Updating / Sending data / Locked，结合执行时间判断是否卡住
- 对长时间运行的线程，可执行 SHOW ENGINE INNODB STATUS\G，在 TRANSACTIONS 部分找详细锁信息和最近SQL
分析锁的来源和优化方向
常见锁等待原因和对应动作：
- 长事务未提交：业务代码漏掉 commit/rollback，或事务内混入耗时操作（如HTTP调用、文件读写）。→ 检查应用逻辑，加超时控制，避免在事务里做非DB操作
- 无索引导致全表扫描加锁：UPDATE/DELETE WHERE 条件列没走索引，会锁整张表或大量无关行。→ 用 EXPLAIN 确认执行计划，补上合适索引
- 间隙锁（Gap Lock）冲突：RR隔离级别下，范围条件 UPDATE 或唯一键重复插入易触发。→ 考虑是否真需RR，或改用RC（注意幻读风险）
- 高并发热点行更新：比如库存扣减、计数器累加。→ 改用乐观锁（version字段）、Redis预减、或拆分热点（如分段库存）
临时止血与长期预防
紧急情况下可 kill 掉阻塞源头：
- KILL [blocking_thread_id];（谨慎操作，确认不是关键业务事务）
- 设置事务超时：SET innodb_lock_wait_timeout = 10;（默认50秒，按业务容忍度调低）
- 监控常态化：用 pt-deadlock-logger 定期抓死锁；用 Prometheus + mysqld_exporter 监控 lock_wait_time、innodb_row_lock_waits
- 开发规范：所有事务明确 BEGIN/COMMIT 边界；禁止在事务中 sleep、调外部接口；DML 必须带 WHERE 且确保走索引
