1. 基本概念与锁模型
1.1 锁的基本类型与作用
在 MySQL 的并发控制中，锁的类型和粒度直接决定了事务的隔离性和系统的吞吐量。行级锁通常用于 InnoDB 的多行并发，表锁在极端场景下授予整表的独占控制，而 意向锁则帮助数据库管理锁的层级关系，降低锁冲突的成本。
理解这几种锁的差异，有助于在高并发场景中快速定位锁竞争根因：是哪个对象、哪个事务在占用锁，还是谁在等待。锁信息查看的目的就是将这类信息从隐性状态转换为可分析的数据。
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_TRX;
通过这些信息可以看到当前锁的对象、锁模式、以及等待关系。锁等待与 死锁是分析的核心指标，往往需要结合 事务信息 一起解读。
1.2 观察锁的时序与死锁信号
在日常排查中，SHOW ENGINE INNODB STATUS是最直观的诊断入口。输出中的 LATEST DETECTED DEADLOCK 区段可以帮助定位死锁链路，包含参与事务、等待关系以及被等待的对象信息。
当出现长时间的锁等待时，锁等待信息和 事务状态的组合往往透露瓶颈所在，结合监控数据可以还原出等待链路的拓扑结构。
SHOW ENGINE INNODB STATUS\G此外，结合信息模式中的锁和事务表，可以获得历史和当前的锁信息，从而对比异常时段的变化趋势。信息模式查询是快速核对锁对象与事务之间关系的有效方式。
2. 常用命令查看锁信息
2.1 查看当前会话与锁状态的命令
第一步通常是获取当前会话和系统层面的锁竞争态势。SHOW PROCESSLIST提供活跃的线程视图，帮助发现被阻塞的连接与执行中的查询。
紧随其后，SHOW ENGINE INNODB STATUS会给出锁等待和死锁的即时快照，便于定位具体的等待对象和等待模式。
SHOW PROCESSLIST;
SHOW ENGINE INNODB STATUS\G此外，直接查询信息模式中的锁与事务也能快速定位问题：INNODB_TRX显示当前活跃的事务信息，INNODB_LOCKS与 INNODB_LOCK_WAITS展现锁的持有和等待关系。
SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
2.2 基于信息模式的综合锁诊断
对于持续性的锁问题，推荐把信息模式与历史数据结合起来分析。INNODB_LOCK_WAITS能帮助识别等待中的锁对象，INNODB_LOCKS提供锁的粒度信息，进而与 INNODB_TRX 关联，形成完整的等待链路画像。
通过查询结果，可以看到等待的事务 trx_id、锁的类型、锁模式以及被锁表的名称，从而在应用层面定位到具体的业务 SQL。
SELECT l.lock_id, l.lock_type, l.lock_mode, t.trx_id, t.trx_state
FROM information_schema.INNODB_LOCKS AS l
JOIN information_schema.INNODB_TRX AS t ON l.lock_trx_id = t.trx_id
WHERE l.lock_wait = 'YES';
3. 使用 Performance Schema 进行锁诊断
3.1 Performance Schema 的锁相关表
Performance Schema 提供了更细粒度的锁监控能力，适合持续化、纵向的性能分析。performance_schema.data_locks记录当前锁的详细信息，performance_schema.data_lock_waits记录等待中的锁事件，能帮助追踪等待链路的实时状态。
在启用 Performance Schema 之后，可以通过简单的查询来获取锁的分布、等待时间和相关的线程信息，从而构建锁竞争的全景图。
SELECT * FROM performance_schema.data_locks;
SELECT * FROM performance_schema.data_lock_waits;
另外，结合 performance_schema.threads 和 performance_schema.events_waits_summary_by_instance 等表，可以把锁信息与具体执行的线程、SQL 文本对应起来，便于定位具体的延时点。
SELECT t.thread_id, t.processlist_id, t.PROCESSLIST_ID, t.NAME
FROM performance_schema.threads AS t;
3.2 如何从 Performance Schema 追踪等待链
追踪等待链通常需要把等待事件与锁对象建立关系。通过 JOIN performance_schema 的相关表，可以把等待的线程、锁对象和执行的 SQL 关联起来，从而还原出“谁在等待谁”的链路。
常见的分析步骤包括：启用等待事件采样、聚合等待时间分布、以及对比同段时间的锁等待变化。对高并发场景，这种方法能持续提供可观测性。
SELECT w.event_name, w.timer_wait, t.thread_id, t.processlist_id
FROM performance_schema.events_waits_summary_by_instance AS w
JOIN performance_schema.threads AS t ON w.thread_id = t.thread_id
WHERE w.event_name LIKE 'wait/lock%';
4. 死锁排查与历史分析
4.1 死锁检测与日志分析
死锁通常由互相等待的事务构成，最新检测到的死锁信息会出现在 SHOW ENGINE INNODB STATUS 的相应区段。结合
对死锁进行排查，除了直接查看 LATEST DETECTED DEADLOCK，还应关注参与死锁的事务文本、锁等待的对象以及被锁定的资源。
SHOW ENGINE INNODB STATUS\G
为了历史追踪，可以把 Performance Schema 的等待事件与锁信息进行定期采集，构造死锁发生前后的对比视图，从而帮助理解死锁发生的模式与触发条件。通过下列查询，可以快速定位历史阶段的锁等待峰值与死锁事件的关联性：基于历史的锁等待统计查询。
SELECT *
FROM performance_schema.events_waits_summary_by_instance
WHERE EVENT_NAME LIKE 'wait/lock%'
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;
