在MySQL的InnoDB存储引擎中，事务锁等待是指一个事务在申请锁资源时，由于该资源已被其他未提交事务占用，而不得不进入阻塞状态的现象。当并发事务对相同数据行或间隙进行操作且加锁顺序不同，或者某个事务长时间未提交，就会形成锁等待甚至死锁。理解锁等待的产生机制，是进行针对性优化的第一步。InnoDB采用的是行级锁，配合MVCC多版本并发控制，读不加锁而写加锁，但一旦写事务之间发生冲突，等待便不可避免。
锁等待的底层原理与常见触发场景
InnoDB的锁系统由事务系统、锁管理器和等待队列组成。每个事务在修改数据时会申请记录锁（Record Lock）、间隙锁（Gap Lock）或临键锁（Next-Key Lock）。例如执行UPDATE user SET age=20 WHERE id=5时，若id是主键，仅对id=5这一行加记录锁；若id不是索引，则会升级为全表扫描并对扫描到的行加锁，极大增加冲突概率。锁等待的本质是事务T2请求的锁与事务T1持有的锁模式不兼容，如S锁与X锁互斥。
常见的触发场景包括：第一，长事务持锁不释放，比如事务中包含远程接口调用或人工审核步骤，导致后续短事务全部堆积；第二，加锁顺序不一致引发死锁等待，事务A先锁id=1再锁id=2，事务B先锁id=2再锁id=1，互相阻塞；第三，缺乏合适索引导致锁范围扩大。在RR隔离级别下，即使命中索引，也会加间隙锁防止幻读，若查询条件跨度大，会锁住大量间隙。
我们可以通过以下SQL观察当前锁等待情况，这是排查的基础手段：
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM information_schema.innodb_lock_waits w JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;
事务层面的优化策略与实践
缩短事务长度是缓解锁等待最直接的方式。开发中应把事务范围控制在最小的必要逻辑内，避免将文件上传、消息推送、外部HTTP请求放入数据库事务中。例如电商扣库存操作，应先在事务中完成库存行更新并立即提交，再通过异步队列发送通知，而不是在事务里同步调用短信接口。这样持有X锁的时间从秒级降到毫秒级，并发能力显著提升。
统一加锁顺序是避免死锁导致等待的关键实践。当业务需要更新多个账户或订单时，所有事务都应按主键ID升序加锁。可以在代码层面对ID集合排序后再执行更新，或者使用SELECT ... FOR UPDATE时显式按ORDER BY主键查询。如下代码展示了先排序再加锁的写法：
List<Long> ids = Arrays.asList(3L, 1L, 2L);
Collections.sort(ids); // 统一升序，避免交叉加锁
String joined = ids.stream().map(String::valueOf).collect(Collectors.joining(","));
jdbcTemplate.query("SELECT * FROM account WHERE id IN (" + joined + ") ORDER BY id FOR UPDATE", rs -> {
// 处理逻辑
});
此外，合理设置innodb_lock_wait_timeout参数（默认50秒）可以让等待超时快速失败，防止雪崩。对于非核心链路，可设为3到5秒，并在应用层捕获异常后重试。同时开启innodb_deadlock_detect让引擎自动回滚代价小的事务，减少人工介入。
索引与SQL写法对锁等待的影响
索引缺失是锁等待被放大的隐性原因。在RR级别下，若WHERE条件无索引，InnoDB会进行全表扫描，对每一行加记录锁和间隙锁，相当于表级锁。为验证这一点，我们对比有索引与无索引的更新锁范围：
| 场景 | WHERE条件 | 锁定范围 | 并发影响 |
|---|---|---|---|
| 有主键索引 | id=10 | 仅id=10行 | 极低 |
| 有二级索引 | status=1 | 匹配行及间隙 | 中等 |
| 无索引 | name='test' | 全表行及间隙 | 极高 |
因此，所有高频更新字段都应建立合适索引。但需注意，即使是索引字段，若使用函数或隐式转换也会导致索引失效，例如WHERE DATE(create_time)=CURDATE()会使索引不可用。应改写为范围查询以命中索引，缩小锁边界。
在SQL写法上，能用INSERT IGNORE或UPSERT（INSERT ... ON DUPLICATE KEY UPDATE）替代先查后改的场景，可以减少SELECT FOR UPDATE的使用。因为前者在冲突时由引擎原子处理，避免事务间先读锁再写锁的间隙。如下示例展示了UPSERT减少锁等待的用法：
INSERT INTO counter (page_id, views) VALUES (1001, 1) ON DUPLICATE KEY UPDATE views = views + 1;
最后，监控体系不可或缺。应定期采集performance_schema.events_waits_current中锁等待事件，并结合慢日志中lock_time字段分析趋势。当单位时间锁等待次数突增，往往是新上线SQL或流量模型变化所致，需及时回滚或优化。通过原理理解、事务控制、索引优化与监控闭环，MySQL事务锁等待问题才能被系统性地解决。