查看死锁日志
通过一下命令行查看到死锁日志
show engine innodb status
死锁日志分析
日志1
①：表示事务1的id是39474。
②和③：表示事务1执行
DELETE FROM T1 WHERE ID=4时发送了阻塞，WAITING FOR THIS LOCK TO BE GRANTED表示的就是事务发生了阻塞。
④：这个需要重点关注下，
index PRIMARY指的是②处的sql的索引计划是PRIMARY KEY。我们需要重点关注下②处的sql是否走索引了，如果没有走索引将会扫描全表，扫描全表将会对全表数据加锁，未走索引导致扫描全表也是出现死锁的概率最大的一种可能。
⑤⑥⑦⑧：事务1执行②这条sql时需要对⑥⑦⑧这条数据加
x锁，⑤处的意思就是对这条数据加x锁时发送了阻塞，继而可以推断这条数据已经在别的事务中被加上了锁而且加的是x锁，看①⑤处发现这条数据在事务2中被加上了x锁。
⑥⑦⑧：是指事务1中需要获取所锁的这条数据的相关信息，⑥处表示的是id=4,⑦处表示的是事务id为
00000009a33,这是16进制，转化为10进制后为39475,正好是事务2⑨的id,表示的是事务2获取了id为4这条数据的锁。需要注意的是⑥处并不是永远都是id,⑦处并不是永远都是事务id,这里展示的信息是与2处的sql相关的。
⑨：表示事务2的id是39475。
①②和①③和①④和①⑤：表示执行①②这条sql时，事务2当前持有的锁信息
HOLDS THE LOCKS，一共持有3条数据的锁(①⑤处)，而这3条数据的锁是通过①③index PRIMARY主键索引获取的 X锁①④。这里可以看到3条数据中的第一条数据由于事务2获取了x锁而导致事务1出现了阻塞。
①⑥：表示事务2执行SQL①①时需要对在
PRIMARY INDEX①⑦索引上的①⑨这条数据上加x锁①⑧锁时发送了阻塞，而①⑨这条数据在死锁日志中并没有看到被哪个事务HOLDS THE LOCKS了，但是可以推断肯定是事务1获取到了①⑨这条数据的锁，进而造成俩个事务的死锁，最后ROLL BACK TRANSACTION(2)表示事务2回滚。
推断俩事务执行顺序为
日志2
这是一个多进程脚本
并发且批量插入造成的一个死锁日志。
在日志1中介绍过的这里就不在赘述了，主要看下以下几点：
②：事务1执行②处的sql发生了阻塞，②处的sql类似如下
INSERT INTO car_rent_reduce_detail (
MONTH,
courier_id,
asset_code,
area_code,
dept_code,
car_rent_sum,
rent_reduce_rate,
.....
)
VALUES
('202209','01409103','111','755Y','755A',40,50,....),
('202209','01409103','111','755Y','755A',40,50,....),
('202209','01409103','111','755Y','755A',40,50,....)
ON DUPLICATE KEY UPDATE
car_rent_sum = VALUES( car_rent_sum ),
rent_reduce_rate = VALUES(rent_reduce_rate)
④：表示sql②的执行计划索引是month_2,而month_2是一个联合唯一索引
UNIQUE KEY `month_2` (`month`,`courier_id`,`asset_code`,`area_code`,`dept_code`)
⑤和⑥：事务1在执行②处的sql时，需要对⑥处的数据加锁时发生了阻塞，具体信息是将⑥这条数据插入到缝隙时，也就是对缝隙加insert intetion插入意向锁时加不上，因为该缝隙已经被加上了gap锁，这里需要思考一下insert操作在什么情况下会加gap锁？只有在插入发生唯一键冲突的时候,冲突数据的俩边间隙会加上gap锁。
①0️⃣：事务2在执行sql⑧时,已经(正在)持有的数据锁是①②以及下面框住的俩行数据，可以看到这俩条数据加的是S锁，insert操作在什么情况下会加S锁呢？也是在发送主键冲突的时候，冲突的这条数据会被加上S锁，眼尖的同学已经观察到①②下面的那条数据和事务1发送阻塞的数据是一个的，简单说就是事务2已经获取了那条数据的锁，而事务1又插入了相同的数据导致主键冲突。
①③：事务2在插入①⑥这条数据的时候发生了阻塞，可以推断这条数据是事务1已经插入过了，导致事务2发生阻塞。
推断俩事务执行顺序为：
唯一键冲突是并发批量插入导致死锁的根本原因，因为发生唯一键冲突会加gap锁。
不管是insert into.....还是insert into ...on duplicate update key,发送唯一键冲突在并发的场景下都有可能发送死锁，具体原因看上篇文章
并发、批量插入导致死锁问题的解决方案
并发也就意味着是多个事务同时执行，而批量插入又是一个大的事务，这样就增大了死锁的概率。
如果是单进程执行，肯定不会出现死锁，死锁出现的前提是多个事务同时执行。
那出现问题时怎么解决呢？
- 上数据来源出发，聚合唯一键数据，避免产生唯一键冲突
- 如果避免不了唯一键重复数据，则降低并大量或者降低批量插入值，这样方式只是能降低出现死锁的概率
- 可以让一个进程先插入一会数据，此时其他进程休眠，目的是让第一个进程产生足够多的间隙，这样出现死锁的概率也会降低