InnoDB锁等待的本质是事务之间对同一行数据的竞争，解决路径无非两条：缩短持有锁的时间，或者提高等待的容忍上限，真正的高手，会把功夫花在SQL设计和索引优化上，而不是等到线上告警才去查。
InnoDB启动时为什么会出现锁等待
很多人在MySQL刚启动、业务还没跑热的时候就撞上锁等待，第一反应是“数据库坏了”，其实不是，InnoDB启动后的最初几分钟，恰恰是锁冲突的高发期：连接池里的线程同时涌进来，批量任务、定时脚本、缓存回填一起抢同一批热点行。
锁等待的根源：事务并发与行锁机制
InnoDB默认的行锁粒度是索引记录锁，两个事务同时修改同一行，后到的那一方不会立刻报错，而是进入等待状态，这个等待是有上限的，超过阈值就抛出Lock wait timeout exceeded。
在InnoDB的机制里，绝大多数锁等待发生在写事务之间，读操作走MVCC多版本控制，基本不参与行锁竞争,这也是为什么排查时优先盯写操作。
启动阶段锁等待的特殊场景
MySQL启动时如果触发了崩溃恢复，InnoDB需要回放redo log并清理未提交事务，此时如果有应用连接提前涌入，就可能出现启动初期的短暂锁等待，碰到这种情况，别急着kill进程，先看SHOW ENGINE INNODB STATUS里的事务列表。
innodb锁等待怎么解决？先分清等待和死锁的区别
这是新手最容易混淆的地方，锁等待和死锁虽然都表现为“拿不到锁”,但处理方式完全不同。
锁等待 vs 死锁：本质有什么不同
| 维度 | 锁等待 | 死锁 |
|---|---|---|
| 参与方 | 一方等待，一方持有 | 双方互相等待对方释放 |
| 结果 | 超时后自动回滚等待方 | InnoDB检测后主动回滚代价较小的事务 |
| 报错信息 | Lock wait timeout exceeded | Deadlock found |
| 是否需要人工干预 | 优化SQL或调整超时参数 | 多数情况下自动解除，但需优化加锁顺序 |
简单记：锁等待是单行道堵车，死锁是十字路口互相顶住，堵车等一等能过去，顶住了必须有人倒车，业内专家指出，死锁检测本身消耗性能，高并发下频繁触发时,可以考虑用锁等待超时来控制。
常见的锁等待场景案例
- 一个事务里先更新订单状态，再去更新用户积分，另一个事务反着来，相互等
- 批量UPDATE语句没有走索引，导致InnoDB锁范围扩大，从行锁波及到间隙锁
- 事务里混入远程调用或大量计算，锁迟迟不释放
innodb锁等待超时设置：从参数到场景调优
innodb_lock_wait_timeout是控制锁等待时长的核心参数，默认值是50秒，这个值对大多数OLTP业务来说偏长,因为等50秒的事务往往已经拖垮了连接池。
核心参数：innodb_lock_wait_timeout
查看当前值：
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
动态调整：
SET GLOBAL innodb_lock_wait_timeout = 20; SET SESSION innodb_lock_wait_timeout = 20;
注意：全局参数对已建立的连接不生效，需要新连接才会读取新值，生产环境建议写入配置文件my.cnf的[mysqld]段,保证重启后依然有效。
不同场景下的超时时间配置建议
| 业务场景 | 建议超时时间 | 理由 |
|---|---|---|
| 高并发秒杀 | 5-10秒 | 快速失败，避免连接堆积 |
| 一般OLTP业务 | 15-30秒 | 给短事务足够时间完成 |
| 后台批处理 | 50-100秒 | 批量任务本身耗时较长 |
| 数据订正脚本 | 自定义 | 分批执行，避免长事务 |
配置超时时间只是兜底手段，行业共识认为，长期依赖调大超时参数来规避锁等待，相当于用止痛药掩盖病灶,真正要解决的是SQL层面的问题。
mysql锁等待怎么看？排查命令实操清单
锁等待是动态问题，光看错误日志不够,得在它发生的那一刻抓现场。
查看当前锁等待的几种方式
SHOW ENGINE INNODB STATUS
SHOW ENGINE INNODB STATUSG
重点看LATEST DETECTED DEADLOCK和TRANSACTIONS两个段落，如果当前有锁等待,这里会列出等待事务和持有锁的事务。
查询information_schema
SELECT FROM information_schema.INNODB_TRX; SELECT FROM information_schema.INNODB_LOCKS; SELECT FROM information_schema.INNODB_LOCK_WAITS;
三个表联合起来看，能清晰看到谁在等谁，MySQL 8.0中这些表更名为performance_schema.data_locks和data_lock_waits,查询方式略有调整。
performance_schema监控
SELECT FROM performance_schema.events_statements_current WHERE THREAD_ID IN (SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID IS NOT NULL);
定位阻塞源头的方法
锁等待的肇事者通常是某个长时间未提交的事务,排查思路：
- 先看
INNODB_TRX里trx_started字段，找出运行时间最长的事务 - 用
SHOW PROCESSLIST看这个事务当前执行的SQL - 如果事务卡在非SQL操作上，比如应用层代码执行了远程调用，需要回查应用日志
- 确认后，用
KILL命令终结阻塞事务：
KILL 12345;
相当一部分线上锁等待，根源不是SQL本身，而是应用层在事务里做了接口调用或文件操作，这类问题改SQL没用,得改代码结构。
杜绝锁等待的日常习惯
排查是救火,预防才是日常。
- 事务保持短小：一个事务里只做必须的写操作，别在事务里查报表、调接口
- SQL走索引：让UPDATE和DELETE语句精准命中索引，避免锁范围扩大
- 统一加锁顺序：多个表更新时，固定按照同一顺序操作，减少死锁概率
- 错峰执行批量任务：大批量UPDATE拆成小批次，每批之间sleep几秒
- 监控长事务：设置告警，事务超过阈值就通知开发介入
InnoDB锁等待不是bug，是并发场景下的正常现象，真正的问题在于当锁等待发生时，你是否知道背后的代价，把超时参数调到一个合理的值，把SQL和事务设计做好,锁等待自然就少了。
Q&A：innodb锁等待常见问题
问：innodb锁等待超时后，事务会回滚吗？
会根据innodb_rollback_on_timeout参数决定，默认情况下该参数为OFF，MySQL只回滚当前报错的SQL语句，事务本身不会自动回滚，如果需要整个事务回滚,需要开启该参数或在应用层捕获异常后手动回滚。
问：innodb锁等待和死锁有什么区别？
锁等待是单个方向上的等待，另一方持有锁并且正常执行，等待方超过innodb_lock_wait_timeout后报错，死锁是循环等待，双方各持有一把锁并且都等对方释放，InnoDB检测后会主动回滚代价较小的事务，锁等待可以通过调大超时参数缓解,死锁调大超时参数没有意义。
问：怎么快速定位innodb锁等待的阻塞源头？
先查information_schema.INNODB_TRX和INNODB_LOCK_WAITS两张表，找到等待关系中最上层的那个事务ID，再通过SHOW PROCESSLIST查看该事务当前执行的SQL，确认是死锁还是长时间未提交，如果是应用层原因，结合业务日志定位具体代码位置，最后用KILL清理阻塞事务。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/574281.html
