标签：方法 update size unique 准备 auto redirect bsp root
https://mp.weixin.qq.com/s/2obpN57D8hyorCMnIu_YAg
转 | 来源：公众号yangyidba
死锁其实是一个很有意思也很有挑战的技术问题，大概每个 DBA 和部分开发朋友都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助。
业务上的主要逻辑:
首先执行插入数据，如果插入成功，则提交。如果插入的时候报唯一键冲突，则执行更新。 如果同时出现三个并发在执行数据初始化动作，sess1 插入成功，sess2 和 sess3 插入遇到唯一键冲突，插入失败，则都执行执行更新，于是出现死锁。
MySQL 5.6.24 事务隔离级别为 RR
create table ty (
id int not null primary key auto_increment ,
c1 int not null default 0,
c2 int not null default 0,
c3 int not null default 0,
unique key uc1(c1),
unique key uc2(c2)
) engine=innodb ;
insert into ty(c1,c2,c3) values(1,3,4),(6,6,10),(9,9,14);
为了方便分析死锁日志，三个会话插入的 c3 的值分别为1 2 3 ，生产上其实是相同的值。
2018-03-28 10:04:52 0x7f75bf2d9700
*** (1) TRANSACTION:
TRANSACTION 1870, ACTIVE 76 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 399265, OS thread handle 12, query id 9 localhost root updating
update ty set c3=5 where c1=4
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 28 page no 4 n bits 72 index uc1 of table `test`.`ty` trx id 1870 lock_mode X locks rec but not gap waiting
*** (2) TRANSACTION:
TRANSACTION 1871, ACTIVE 32 sec starting index read, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 399937, OS thread handle 16, query id 3 localhost root updating
update ty set c3=5 where c1=4
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 28 page no 4 n bits 72 index uc1 of table `test`.`ty` trx id 1871 lock mode S
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 28 page no 4 n bits 72 index uc1 of table `test`.`ty` trx id 1871 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (2)
其实单单从日志上查看只看到两个事务的 update 相互竞争，在缺乏业务逻辑场景的情况下，很难得到有效思路。
T2 s1 执行 insert 操作，检查唯一性且插入成功,持有 c1=4 记录行的行锁。
T3 s2 insert遇到唯一键冲突，申请加锁 Lock S Next-key Lock 日志显示为 index uc1 of table test.ty trx id 1870 lock mode S waiting
T4 与 s2 相同, s3 insert 遇到唯一键冲突，申请加锁 Lock S Next-key Lock 日志显示为 index uc1 of table test.ty trx id 1870 lock mode S waiting
T5 sess1 执行 commit 操作, 此时 sess2 和 sess3 同时获取 Lock S Next-key Lock。
T6 应用收到唯一键冲突，sess2 执行 update 操作需要申请 c=4 的行锁，与 sess3的持有的 Lock S Next-key Lock 不兼容，等待 sess3 释放Lock S Next-key Lock。
T7 与sess2 类似 sess3 执行update 操作需要申请 c=4 的行锁，与 sess2 的持有的 Lock S Next-key Lock 不兼容，等待 sess2 释放 Lock S Next-key Lock 。出现循环等待，发生死锁。
本案例的解决方式其实和前文 死锁案例之七 一致，使用 insert on duplicate key。案例七与本案例导致死锁业务逻辑极为相似，为什么呢？因为都是同一组开发哥哥写的。
导致死锁的根本原因是不同事务申请锁的顺序不一样出现循环等待，开发同学在设计高并发的业务场景时，需要着重思考这一点，并且尽量规避业务场景设计不合理导致死锁。
另外就是 insert 的加锁机制相对 update 其实比较复杂，需要多动手实践，理清加锁流程。
扩展阅读
1. 漫谈死锁
2. 如何阅读死锁日志
3. 死锁案例一
4. 死锁案例二
5. 死锁案例三
6. 死锁案例四
7. 死锁案例五
8. 死锁案例六
9. 死锁案例七
https://mp.weixin.qq.com/s/ZknxiA5RuRZpefbF1bM82Q
死锁，其实是一个很有意思也很有挑战的技术问题，大概每个 DBA 和部分开发同学都会在工作过程中遇见 。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助。
业务开发同学想同步数据，他们的逻辑是通过 update 更新操作，如果更新记录返回的 affect_rows为0，然后就调用 insert 语句进行插入初始化。如果插入失败则再进行更新操作，多个会话并发操作的情况下就出现死锁。
MySQL 5.6.24 事务隔离级别为 RR
create table ty (
id int not null primary key auto_increment ,
c1 int not null default 0,
c2 int not null default 0,
c3 int not null default 0,
unique key uc1(c1),
unique key uc2(c2)
) engine=innodb ;
insert into ty(c1,c2,c3)
values(1,3,4),(6,6,10),(9,9,14);
2018-03-27 17:59:23 0x7f75bf39d700
*** (1) TRANSACTION:
TRANSACTION 1863, ACTIVE 76 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 382150, OS thread handle 56640, query id 28 localhost root update
insert into ty (c1,c2,c3) values(3,4,2)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 28 page no 5 n bits 72 index uc2 of table `test`.`ty` trx id 1863 lock_mode X locks gap before rec insert intention waiting
*** (2) TRANSACTION:
TRANSACTION 1864, ACTIVE 65 sec inserting, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 382125, OS thread handle 40032, query id 62 localhost root update
insert into ty (c1,c2,c3) values(3,4,2)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 28 page no 5 n bits 72 index uc2 of table `test`.`ty` trx id 1864 lock_mode X locks gap before rec
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 28 page no 4 n bits 72 index uc1 of table `test`.`ty` trx id 1864 lock mode S waiting
*** WE ROLL BACK TRANSACTION (2)
首先我们要再次强调 insert 插入操作的加锁逻辑。
第一阶段: 唯一性约束检查，先申请 LOCK_S + LOCK_ORDINARY
第二阶段: 获取阶段一的锁并且 insert 成功之后,插入的位置有 GAP 锁：LOCK_INSERT_INTENTION，为了防止其他 insert 唯一键冲突。
新数据插入完成之后：LOCK_X + LOCK_REC_NOT_GAP
对于 insert 操作来说，若发生唯一约束冲突，则需要对冲突的唯一索引加上 S Next-key Lock。从这里会发现，即使是 RC 事务隔离级别，也同样会存在 Next-Key Lock 锁，从而阻塞并发。然而，文档没有说明的是，对于检测到冲突的唯一索引，等待线程在获得 S Lock 之后，还需要对下一个记录进行加锁，在源码中由函数row_ins_scan_sec_index_for_duplicate 进行判断.
其次 我们需要了解锁的兼容性矩阵。
从兼容性矩阵我们可以得到如下结论:
INSERT 操作之间不会有冲突。
GAP，Next-Key 会阻止 Insert。
GAP 和 Record，Next-Key 不会冲突。
Record 和 Record、Next-Key 之间相互冲突。
已有的 Insert 锁不阻止任何准备加的锁。
已经持有的 GAP 锁会阻塞插入意向锁 INSERT_INTENTION。
另外 对于通过唯一索引更新或者删除不存在的记录，会申请加上 GAP 锁。
了解上面的基础知识，我们开始对死锁日志进行分析:
T1: sess1 通过唯一键更新数据，由于 c2=4 不存在，返回 affect row 为 0，MySQL 会申请(3,6)之间的 GAP 锁。
T2: sess2 的情况和 sess1 类似，也会申请(3,6)之间的 GAP 锁，从上面的兼容性矩阵来看两个 GAP 锁并不会冲突。
T3: sess1 根据 update 语句返回 affect row 为 0，执行 insert 操作，此时需要申请插入意向锁，sess2 会话持有的 GAP 锁和 sess1 申请的插入意向锁冲突，出现等待。
index uc2 of table test.ty trx id 1863 lock_mode X locks gap before rec insert intention waiting
T4:sess2 与 sess1类似，根据 update 语句返回 affect row 为 0，执行 insert 操作。 申请的插入意向锁与sess1 的 update 语句持有的 GAP 锁冲突。sess1（持有 GAP 锁），sess2（持有 GAP 锁），sess1（插入意向锁等待 sess2 的 GAP 锁释放） sess2（插入意向锁等待 sess1 的 GAP 锁释放） 构成循环等待，进而导致死锁。
从业务场景的处理逻辑上看，业务需要发送两次请求一次 update，一次 insert 才能完成业务逻辑，不够友好和优化。
其实我们可以和开发同学沟通好，确认业务的幂等性，使用 insert on duplicate key的方式，没有就插入，存在就更新，一次调用即可完成之前 2 次操作的功能，提高性能。
最后想说关于解决死锁问题的思路:
1. 具备扎实的锁相关的基础知识。
2. 单单根据死锁日志其实比较难以判断具体的 sql 执行情况，需要和开发同学沟通好，理清业务执行 sql 的逻辑，然后去模拟测试。
标签：方法 update size unique 准备 auto redirect bsp root
原文地址：https://www.cnblogs.com/rsapaper/p/13334023.html
