死锁是数据库运维和开发中最让人头疼的问题之一：业务代码没有任何改动，数据库却突然大面积超时，应用日志里刷出大量死锁异常，严重时整个服务的写请求全部阻塞。要彻底解决这类问题，不能只靠重启数据库临时缓解，必须理解锁的工作机制，掌握监控手段，并学会从系统视图和日志中定位到具体的事务和SQL语句。本文以MySQL的InnoDB为主要例子，讲解锁监控与死锁排查的完整思路。
一、先搞清楚数据库里有哪些锁
排查问题的第一步是理解锁的类型和加锁范围。InnoDB的锁体系可以分为两个维度：锁的模式和锁的粒度。从模式上看，最基础的是共享锁（S锁）和排他锁（X锁）。共享锁允许多个事务同时读同一行数据，而排他锁是互斥的，一个事务持有某行的排他锁后，其他事务既不能读也不能写这一行（在不使用MVCC快照读的前提下）。
从粒度上看，InnoDB既有行级锁，也有表级锁和意向锁。值得注意的是，InnoDB的行锁并不是直接锁住某一行记录，而是加在索引项上的。这意味着如果UPDATE或DELETE语句的WHERE条件没有命中任何索引，InnoDB只能沿着聚簇索引全表扫描，把扫描到的每一行都加上锁，实际效果接近锁全表。这是很多"我只更新一行为什么锁了整张表"问题的根源。
在默认的可重复读（REPEATABLE READ）隔离级别下，还存在间隙锁（Gap Lock）和临键锁（Next-Key Lock）。间隙锁锁的是索引记录之间的区间，目的是防止幻读。举个例子，事务A执行SELECT * FROM orders WHERE amount > 100 FOR UPDATE，即使orders表中amount大于100的记录只有3条，InnoDB也可能把100到正无穷之间的整个区间都锁住，导致其他事务插入amount为200的记录时被阻塞。理解这一点对分析死锁日志至关重要。
二、如何实时监控锁等待
当数据库出现阻塞时，第一件事是找到谁在等谁。MySQL 8.0提供了非常方便的performance_schema和sys库，可以直接查询锁等待关系：
-- 查看当前锁等待情况，直接给出阻塞源
SELECT
waiting.pid AS waiting_pid,
waiting.trx_id AS waiting_trx,
waiting.trx_mysql_thread_id AS waiting_thread,
waiting.trx_query AS waiting_query,
blocking.pid AS blocking_pid,
blocking.trx_id AS blocking_trx,
blocking.trx_mysql_thread_id AS blocking_thread,
blocking.trx_query AS blocking_query
FROM sys.innodb_lock_waits AS w
JOIN information_schema.innodb_trx waiting
ON waiting.trx_id = w.waiting_pid
JOIN information_schema.innodb_trx blocking
ON blocking.trx_id = w.blocking_pid;
这个查询会同时列出等待中的SQL和持锁中的SQL，一眼就能看出阻塞链条。如果阻塞源的事务长时间不提交（常见原因是应用代码中事务里夹带了RPC调用或者长时间计算），可以考虑使用KILL <thread_id>终止阻塞事务，但kill之前务必确认该事务的业务影响，避免造成数据不一致。
除了实时查询，还可以开启锁监控持续收集数据。执行SET GLOBAL innodb_status_output_locks = ON;后，SHOW ENGINE INNODB STATUS的输出会包含详细的锁信息段落，可以看到每个事务持有的锁和等待的锁的具体模式（lock_mode X表示排他记录锁，lock_mode X locks gap表示间隙锁）。注意这个开关会带来一定性能开销，排查完问题后建议关闭。
对于周期性出现的锁问题，可以把information_schema.innodb_trx和data_locks表定期写入监控表，配合定时任务抓取长事务。一个事务的trx_started时间距今超过30秒，通常就值得警惕，长事务是锁持有的最大源头。
三、死锁日志怎么读
死锁发生后，InnoDB会自动选择回滚代价较小的事务作为牺牲品，另一个事务继续执行，所以死锁通常表现为业务侧零星报错而不是数据库卡死。要分析死锁，先开启innodb_print_all_deadlocks参数，让每一次死锁都记录到错误日志中，而不是只保留最近一次：
SET GLOBAL innodb_print_all_deadlocks = ON;
拿到死锁日志后，重点关注三个部分。第一部分是两个事务各自持有的锁和等待的锁，比如lock_mode X locks rec but not gap表示记录锁，lock_mode X后面没有附加说明的通常表示临键锁。第二部分是事务执行过的语句历史（HOLDS THE LOCK(S)上方的事务信息中可以看到SQL），第三部分是最终触发死锁的两条SQL。很多死锁的根因不在触发的那两条SQL，而在事务更早执行的语句上，所以不能只看最后一条。
一个经典场景：两个事务同时执行UPDATE account SET balance = balance - 100 WHERE id = 1再UPDATE ... WHERE id = 2，如果事务A先锁1再锁2，事务B先锁2再锁1，加锁顺序相反就必然死锁。日志里表现为事务A持有id=1的记录锁等待id=2，事务B持有id=2的记录锁等待id=1，形成环形等待。解决方法是统一所有事务的加锁顺序，比如按主键升序处理。
另一个高频死锁场景和唯一索引的插入有关：两个事务同时执行INSERT遇到重复键冲突时，会把共享锁升级为排他锁，从而形成S锁与X锁的互相等待。这种情况可以考虑改用INSERT ... ON DUPLICATE KEY UPDATE，或者在应用层先加分布式锁串行化插入。
四、从根源上减少死锁的实践建议
监控和排查解决的是当下的问题，要长期减少死锁，需要在设计和编码层面下功夫。首先是大事务拆分。事务持有的锁在提交或回滚前不会释放，事务越大，持锁时间越长，和其他事务冲突的概率就越高。把一个包含十几条SQL、还夹带外部接口调用的大事务拆成多个短事务，往往能显著降低锁冲突。
其次是索引优化。前面提到，WHERE条件无索引会导致锁范围扩大到全表扫描路径上的所有记录。给 UPDATE和DELETE的过滤条件建好索引，让InnoDB只锁真正需要修改的行，是缩小锁范围最直接的手段。可以用EXPLAIN确认更新语句是否走索引，如果type列显示为ALL，说明在全表扫描，需要优先处理。
第三是降低隔离级别。如果业务对幻读不敏感，可以把隔离级别从REPEATABLE READ降为READ COMMITTED，此时间隙锁基本不再使用，锁范围大幅缩小，很多间隙锁相关的死锁会直接消失。当然这需要评估业务对一致性读的要求，不能盲目修改。
-- 示例：统一加锁顺序的批量更新 START TRANSACTION; -- 先按主键排序，保证所有事务以相同顺序加锁 UPDATE account SET balance = balance - 100 WHERE id IN (1, 2, 3) ORDER BY id; COMMIT;
最后建立常态化的监控告警：对死锁次数、锁等待时长、长事务数量设置阈值告警，配合慢查询日志中的Lock_time字段，可以做到问题发生前发现苗头。死锁不可能百分之百避免，但通过锁范围控制、加锁顺序统一和快速自动重试（应用层捕获死锁异常后小延时重试是标准做法），可以让它对业务几乎无感知。