背景介绍
在数据库系统中，当多个进程并发访问某个数据时，通过加锁机制，可以保证这个数据在任何时刻最多只有一个进程在访问，从而保证数据的完整性和一致性。加锁可能会引发死锁，死锁是指两个或两个以上的进程在执行过程中，因资源争夺而产生的一种互相等待的现象。
死锁的种类比较多，整个锁系统也比较复杂。在 Innodb 锁子系统中，按照粒度分为表级锁，行级锁。行锁里面有间隙锁，插入意向锁，行锁，临键锁。按模式分为互斥锁和共享锁。这些锁中有的锁会互相兼容，有的会冲突。除此之外，隔离级别，数据访问方式对加锁的范围和类型都有影响。
传统死锁定位方法通过查看死锁日志来定位，需要用户对数据库锁系统和死锁日志有一定的了解，定位效率低，对用户的技术水平要求较高。
功能介绍
DBbrain 全新推出死锁可视化分析功能，对数据库的死锁进行智能诊断分析，指引用户使用更优的 SQL 语句来消除不合理的加锁，有效减少慢查询，提升资源使用效率，预防死锁发生。
可视化拓扑图：以可视化的方式展示死锁的拓扑图，帮助用户还原死锁现场，直观展示事务的信息和事务之间的等待关系。
锁信息展示：单击可视化图上的对应锁，即可查看锁的范围，锁住的数据等。
SQL 信息展示：通过 SQL 解析来对执行行为进行推测，帮助用户避免死锁发生。
操作入口
1. 登录 DBbrain 控制台，在左侧导航选择诊断优化，在上方选择对应数据库，然后选择异常诊断页签。
2. 在诊断提示列表中，如果诊断项为死锁，单击查看，即可进入死锁分析及可视化页面。
可视化拓扑图
传统定位死锁的方式是查看死锁日志，通过 
SHOW ENGINE INNODB STATUS 可以查看到 Innodb 最后一次死锁的信息。日志中可以看出 SQL 语句，事务 ID，但是 lock_mode X waiting，hex 80000007 这些数据不是很直观，尤其是死锁中这些锁之间是什么关系，这需要用户对数据库锁系统和死锁日志有一定的了解，才能高效分析和定位。
示例一：两个事务发生死锁
事务1和事务2分别有一个持有的锁（深蓝色线）和一个请求的锁（浅蓝色线），事务1持有的锁阻塞了事务2请求的锁，事务1请求的锁又被事务2持有的锁阻塞，造成死锁。
不兼容的、加在相同记录上面有冲突阻塞关系的锁，使用虚线连接。
示例二：等待解锁时引起死锁
MySQL 中 wait 尽管没有获取成功，还处于 waiting 状态，但一样可以阻塞其他锁的请求，这一点和操作系统中的锁有点不同。
如下图所示，事务2请求的1个行锁（浅蓝色线）被事务1持有的1个行锁（深蓝色线）阻塞了，但事务2的这个行锁又阻塞事务1请求的行锁，造成死锁。
示例三：三个事务发生死锁
事务3请求的 Next_key 锁被事务1持有的行锁（深蓝色线）阻塞了，事务1请求的行锁（浅蓝色线）被事务2持有的行锁（深蓝色线）阻塞，事务2请求的插入意向锁（浅蓝色线）也被事务1的行锁阻塞，三个事务发生死锁。
示例四：引入未知锁（MySQL 5.6，MySQL 5.7）
示例一、二、三是以 MySQL 8.0为例，8.0版本的死锁日志比较全面。事务在请求锁时，如果遇到冲突，是会进行死锁检测的。检查有没有死锁就是去 wait-for graph 中去寻找有没有环。
MySQL 5.6，MySQL 5.7版本仅使用深度优先搜索方法去搜索有没有环，并没有把环记下来，所以在死锁日志中仅保留第一个事务和最后一个事务，死锁日志是不完整了。
针对死锁日志不完整的问题，DBbrain 引入了“未知锁”，使得这个环变得完整。“未知锁”就是我们不知道这是什么锁，但是可以推测这里应该有一把锁，而且它和事务1之间也应该存在一条路径，这条路径可能还有其他事务，所以用虚线表示。
锁信息展示
在死锁日志中，锁信息会展示锁模式（互斥锁，或共享锁），waiting 状态，锁的类型（如行锁，间隙锁，next_key 锁，插入意向锁）。记录锁是加在一个或多个记录上面的，死锁日志上有记录物理地址包括 space，page no 以及 heap no，以及记录所在的 schema，索引等详细信息。使用一个列表来展示记录的数据，但仅打印出了16进制的 Hex 字符串，可读性很差。
SQL 信息展示
定位到具体死锁情况和相关信息还不够，DBbrain 帮助用户做进一步智能诊断。我们在图中加入发生死锁时候的 SQL 语句，并通过注释方式来告诉用户，执行这个 SQL 语句时候发生了什么，MySQL 是使用什么规则来加这个锁，有这些信息会帮助用户优化业务和 SQL，节省排查时间。
在可视化图中，单击等待，即可看到 SQL 语句的详细信息。