5.技术-mysql(五)-死锁

一.背景

   上篇分析了加锁的场景，这一节可以借助对加锁细节的了解来分析程序中出现的死锁。以及避免死锁。本节通过理论结合实践来分析死锁。

二.死锁

   死锁是指两个或两个以上的事物处理过程中，因争夺锁资源而互相等待的一种现象。

三.通过加锁机制分析一个简单的死锁案例

两个事务更新表t_user、t_user1

图1：事务1更新t_user

图2：事务2更新t_user1

图3：可以看出运行两个事务

图4：无锁冲突

此时事务1持有t_user表id=1的X锁

       事务2持有t_user1表id=1的X锁。

接下来模拟AB-BA锁

图5：事务1尝试获取t_user1的锁

图6.此时t_user1表id=1的X锁冲突。

图7.持有t_user1的事务2尝试获取t_user的锁，发生死锁

四.mysql死锁处理机制

innodb中有两种死锁处理机制

等待资源超时

默认参数:innodb_lock_wait_timeout设置锁等待的时间是50s，一旦数据库锁超过这个时间就会报错。

事务在等待锁不会一直等待超过innodb_lock_wait_timeout之后抛错回滚。 

       下面我们操作展示下：

       图1：事务1占用X锁

图2.事务阻塞等待事务1.

图3：运行中的事物

图4：锁等待

图5：阻塞的线程

图6：等待超时回滚 

图7：程序中抛错

结论：事务不会一直等下去，默认50s后等不到会回滚，这个参数也可以更改：

查看参数：SHOW GLOBAL VARIABLES LIKE'innodb_lock_wait_timeout';(单位是秒)

修改参数：set global innodb_lock_wait_timeout=100;

 50s超时回滚，这种机制缺点不适合并发，对于发生死锁等待50S太久。设置的太短也不行可能有的事务真要50S，所以就有了第二种死锁处理机制。

2.等待图(wait-for graph)

   使用持有锁列表和等待锁列表

   由等待事务指向持有事务，组成的图。

   采用深度优先遍历算法如果发线回路则说明发生死锁。

   对比权重和加锁时间，回滚权重小和更晚持有锁的事物。

五.常见发生死锁的案例

a表b表-b表a表型，如前面例子

3个以上并发对唯一索引加锁引起的死锁，详见http://hedengcheng.com/?p=771#_Toc374698307

唯一约束异常加S锁引起的死锁。详见上篇博客。

批量多线程单笔提交造成高并发场景。

六.如何避免死锁

1>.尽肯能小事务，

2>.多张表更新，不同业务对表操作顺序保持一致。

3>.唯一约束异常尽快回滚事务。

4>.根据自身业务设置等待锁超时时间，默认50S。

5>.批量分批提交。

6>.若业务可以接受幻读，则使用Read Commited的隔离级别。

7>.更新删除全部使用主键，否则高并发下容易产生死锁，因为更新一笔数据要对库、表、页、索引加多个锁。交叉下并发下比较容易产生死锁。