一.背景
上篇分析了加锁的场景，这一节可以借助对加锁细节的了解来分析程序中出现的死锁。以及避免死锁。本节通过理论结合实践来分析死锁。
二.死锁
死锁是指两个或两个以上的事物处理过程中，因争夺锁资源而互相等待的一种现象。
三.通过加锁机制分析一个简单的死锁案例
两个事务更新表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>.更新删除全部使用主键，否则高并发下容易产生死锁，因为更新一笔数据要对库、表、页、索引加多个锁。交叉下并发下比较容易产生死锁。
