前言
任何系统不管在什么阶段都需要关注生产环境错误日志，最近几个月内，发现偶尔会出现数据库死锁情况。以前碰到的数据库类错误大部分是SQL语法造成的错误，来到新东家之后才第一次碰到死锁情况，以前是搞游戏开发，现在是搞电商类开发，可能是不同的项目不同的业务的原因吧，查阅了各种资料后发现，是我想错了：（。一般业务瓶颈在数据库层，对于数据库层的问题需要重点关注，以为死锁这种情况是很严重的问题，这个要分情况，偶尔死锁对业务不会有太大的影响，我又想错了：（。
虫子发现
第一次发现死锁很惊讶，这个是什么鬼？不知道是什么原因？不知道怎么解决？不知道会不会影响业务？没有搞清楚这个问题，生怕是业务的定时炸弹，每天心里不踏实。虫子发现如下：
死锁
对数据库记录操作之前，当前线程需要先请求获得相关锁，获得锁之后才会执行SQL语句。锁根据粒度分为表锁和行锁（不是所有存储引擎都支持行锁），锁根据类型分为排他锁和共享锁（不同的操作需要获得的锁类型不同，不同的锁类型行为也不相同）。资源越少，出现死锁的概率会更小，比如只支持表锁的存储引擎会比支持行锁的存储引擎出现的概率更小。
并发事务出现时，当出现多个事务间彼此等待对方资源释放，事务因没有处理完，已经获得锁的资源不会释放，大家彼此这样等待着僵持着，这样会一直下去，死锁就这样产生了。
死锁现象关系型数据库无法避免，不是MySQL 数据库独有。MySQL 数据库会自动检查死锁情况，当发现时，会回滚更简单的事务并返回给线程一个错误。怎么判断哪个事务更简单呢，根据事务影响的纪录行数判断，纪录行数越小被认为更简单。
诊断分析
当出现死锁时，为了解决这个问题，需要诊断分析当时出现死锁的上下文信息以及相关的执行语句，这样才能知道怎么避免。MySQL 数据库只保存最近一次的死锁事务，如果同时有超过2个事务出现死锁，至多只保存2个事务信息。执行MySQL 客户端命令：SHOW ENGINE INNODB STATUS获得最近一次事务死锁相关信息。如果是MySQL 5.6之后的版本，可以打开全局变量innodb_print_all_deadlocks=ON，这样死锁相关信息会保存到MySQL 错误日志中。如果是不支持这个变量的版本，可以采用定时执行客户端命令采集死锁信息，然后保存到日志文件中，每个事务都有唯一编号，可以根据这个去重。当死锁频繁出现时，需要引起注意；当偶尔出现时，可以不用关注。死锁信息格式如下，不同MySQL 版本内容会有点差异，相关说明可以查看参考资料一。
预防措施
知道死锁为何物，以及通过分析诊断日志信息，就可以对症下药了，但是有一些通用的基本原则可以遵守：
1 尽可能保持事务简单以及快速执行；
2 尽可能保持事务影响行数少以及涉及的相关表少；
3 避免使用外键约束，其实大部分应用允许数据冗余的；
4 影响行数大的事务尽量使用相同的排序过滤；
5 数据库并发不高的业务，可以通过某种方式顺序执行语句，一次只执行一个，通过查资料知道一种实现方式：创建一个表，这个表始终只有一条纪录，各个事务通过争夺这个锁来实现线性执行，感觉这个应该没啥用：（;
6 有些场景死锁会检查不到，设置锁的过期时间就很重要了，MySQL可以通过设置选项innodb_lock_wait_timeout;
危害程度
锁资源得不到及时释放，会影响数据库并发处理，如果经常出现死锁，需要及时采取措施处理，如果只是偶尔出现，业务逻辑捕捉到死锁错误可以采取重试执行事务，对业务不会有什么影响，总之具体问题需要具体分析：）
后记
一开始遇到这个问题有点紧张，以为是很严重的问题，无从下手，不了解相关的背景知识嘛，看来人丑还是要多读书啊（：（：
参考资料
【1】How to deal with MySQL deadlocks
https://www.percona.com/blog/2014/10/28/how-to-deal-with-mysql-deadlocks/
【2】deadlock
http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_deadlock
【3】Deadlock Detection and Rollback
http://dev.mysql.com/doc/refman/5.7/en/innodb-deadlock-detection.html
【4】 How to Cope with Deadlocks
http://dev.mysql.com/doc/refman/5.7/en/innodb-deadlocks.html