故障解析丨一次死锁问题的解决
内容提要
通过分析数据库日志和binlog，解决了一次死锁问题。减少唯一索引和避免插入重复值是解决方法。文章介绍了GreatSQL数据库的特点和用途。
延伸解读
死锁成因：唯一索引冲突下的锁等待循环
文章中的死锁源于两个事务对唯一索引 uk_name 的并发插入。T2 先插入 name=11 并持有该记录的 X 锁，T1 随后插入相同值，需获取 S 锁进行唯一性检查，因与 X 锁不兼容被阻塞。之后 T2 插入 name=8，需获取插入意向锁，但该锁与 T1 已持有的 S 锁冲突，T2 也被阻塞，形成循环等待。这提示在 RC 隔离级别下，唯一索引的重复值插入可能引发死锁。
排查手段：利用 performance_schema 与 binlog 还原现场
文章展示了如何通过 performance_schema.threads 和 events_statements_history 获取历史 SQL，结合 innodb status 中的事务信息，复现出导致死锁的完整操作序列。binlog 则用于确认已提交事务的顺序，但被回滚的 T1 语句不会记录，需开启 general log 才能捕获。这些方法为定位死锁提供了可操作的排查路径。
解决思路：减少唯一索引与避免重复插入
针对该死锁，文章给出的解决方法是适当减少 Unique 索引，并避免插入重复值。减少唯一索引可以降低唯一性检查引发的锁冲突概率；避免插入重复值则直接消除了本例中 S 锁与 X 锁的争用场景。这些措施有助于从源头减少类似死锁的发生。
Q&A
什么是死锁问题？
死锁问题是指两个或多个事务在执行过程中互相等待对方释放锁，导致无法继续执行的情况。
如何识别数据库中的死锁？
可以通过分析innodb状态日志和performance_schema获取历史SQL语句来识别死锁。
GreatSQL数据库的特点是什么？
GreatSQL是适用于金融级应用的开源数据库，具有高性能、高安全性和高可靠性等特点。
解决死锁问题的有效方法有哪些？
解决死锁的方法包括减少唯一索引和避免插入重复值。
在GreatSQL中如何设置事务的隔离级别？
在GreatSQL中，可以通过设置事务的隔离级别为Read-Commited来控制事务的并发行为。
死锁是如何在T1和T2事务中产生的？
死锁在T1和T2事务中产生是因为T1尝试获取共享锁而被阻塞，同时T2尝试获取独占锁也被阻塞，导致互相等待。
