导读：引发死锁的原因是什么？如何避免？本文详细介绍了和死锁有关的知识点|mysql事务并发机制详解

导读：引发死锁的原因是什么？如何避免？本文详细介绍了和死锁有关的知识点，通过深入分析MySQL事务和锁的机制，结合案例背景，找到了问题的所在，并梳理了解决方案，详解其原理。希望对同学们有所启发。
一、背景
最近线上消费MetaQ的服务频繁报SQL死锁异常，虽然最终可以基于事务自动回滚和逻辑重试保证最终正确性，但若一直放任不管，海量报警日志会掩盖真正需要紧急处理的异常，同时频繁回滚也会降低消费端的吞吐量。个人通过分析线上服务日志、MySQL死锁日志、梳理MySQL在RR级别下的锁机制，找到了真正的问题所在，并对业务处理逻辑进行了优化，特在此整理出来，互相学习提升，如果文中有错误的地方欢迎指正。
二、知识储备
正所谓“工欲善其事，必先利其器” ，在具体介绍CASE背景和解决方案前，先对需要系统了解的知识点进行详细介绍，以便大家能够快速理解解决方案。
死锁通常是因为两个及以上事务发生了死循环锁依赖，此时不得不回滚来释放锁，那么事务是个什么东西？
1、事务
为什么需要事务？
我们在业务实现时，经常需要保证某一批SQL能够具备ACID特性，如果没有事务，在应用里自己保证将会变得非常复杂， InnoDB引擎引入事务机制，极大简化了我们在此方面的编程模型。
ACID的实现机制是什么？原子性（Atomicity）：事务内SQL要么同时成功要么同时失败，基于UndoLog实现。一致性（Consistency）：系统从一个正确态转移到另一个正确态，由应用通过AID来保证，并非数据库的责任。隔离性（Isolation）：控制事务并发执行时数据的可见性，基于锁和MVCC实现。持久性（Durability）：提交后一定存储成功不会丢失，基于RedoLog实现。
下面简单说下RedoLog、UndoLog在整个执行过程中的流程（此部分可以掠过）：

文章图片
为什么需要UndoLog？
InnoDb为支持回滚和MVCC ，需要旧数据存档， UndoLog就负责存储这些数据，当更新BufferPool数据前，先将之前数据存入UndoLog 。
为什么需要RedoLog？
BufferPool是随机IO以页为单位，性能损耗很大，不可每次提交都同步刷盘，需要后续异步进行。不能同步刷就会有一个问题，如果MySQL宕机，而事务已提交在BufferPool的数据还没有刷到磁盘，就会导致数据丢失持久性无法保证。为此引入RedoLog ，这个文件IO是顺序追加IO且以修改为单位，性能很高，每次事务提交持久化RedoLog到磁盘也不会对性能造成太大影响，如果宕机可以通过重启从redoLog恢复丢失数据。
RedoLog高性能？
映射一段连续的存储空间，保证顺序IO ，数据先写入Buffer ，后一次性批量将事务数据写入磁盘。
2、锁
下面咱们说说InnoDB锁机制（此处重点关注）。
为了控制事务并发时的数据安全，在不同隔离级别下会通过不同的协同机制进行处理。传统隔离机制，完全由锁(LBCC)来处理，但是这样只能满足读并发，会对性能造成很大影响，故而出现了支持读写并发的MVCC 。因为MVCC不涉及此次背景，也不想罗列锁各种类型（避免让大家直接晕在这里），就简单直接的列出update、delete、insert的加锁情况（RC和RR不一样）。
Update&Delete语句加锁
1）聚簇索引（查询命中）
UPDATEstudentsSETscore=100WHEREid=15;

文章图片
RC、RR都是对聚簇索引加X锁。
2）聚簇索引（查询未命中）