使用mysql数据库，在并发加锁的时候不注意，如锁A和锁B，出现锁A等待锁B，锁B又等待锁A的情况，这个时候会引发死锁。一个成熟的数据库，一般都有死锁检测机制，会自动识别死锁的情况。但有时候为了减少死锁检查的性能开销，会选择关闭死锁检测，这个时候如果出现死锁会等待超时才会释放锁的。
关于innodb锁机制需要注意的是：
- InnoDB行锁是通过给索引项加锁实现的，如果没有索引，InnoDB会通过隐藏的聚簇索引来对记录加锁。也就是说：如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁，实际效果跟表锁一样。
- 由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。说白了就是，where id=1 for update 会锁定所有id=1的数据行，如果是where id=1 and name='liuwenhe' for update,这样会把所有 id=1以及所有name='liuwenhe'的行都上排它锁；
- 当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。
- 即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL优化器通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，或者饮食转换，或者like百分号在前等等，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。
MySQL的并发控制有两种方式，一个是 MVCC，一个是两阶段锁协议。那么为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（可串行化调度）。具体的并发控制这里不再展开。咱们继续深入讨论两阶段锁协议。
两阶段锁协议（2PL）
两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁，在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁；在释放一个封锁之后，事务不再申请和获得任何其他封锁。
对应到 MySQL 上分为两个阶段：
- 扩展阶段（事务开始后，commit 之前）：获取锁
- 收缩阶段（commit 之后）：释放锁
就是说呢，只有遵循两段锁协议，才能实现 可串行化调度。
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁，并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁。
MySQL有两种死锁处理方式：
- 等待，直到超时（
innodb_lock_wait_timeout=50s）。 - 发起死锁检测，主动回滚一条事务，让其他事务继续执行（
innodb_deadlock_detect=on）。
由于性能原因，一般都是使用死锁检测来进行处理死锁。
死锁检测
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。
回滚
检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于INFORMATION_SCHEMA.INNODB_TRX表中的trx_weight字段来判断。
如何避免发生死锁
- 收集死锁信息：
- 利用命令 SHOW ENGINE INNODB STATUS查看死锁原因。
- 调试阶段开启 innodb_print_all_deadlocks，收集所有死锁日志。
- 减少死锁：
- 使用事务，不使用 lock tables 。
- 保证没有长事务。
- 操作完之后立即提交事务，特别是在交互式命令行中。
- 如果在用 (SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE)，尝试降低隔离级别。
- 修改多个表或者多个行的时候，将修改的顺序保持一致。
- 创建索引，可以使创建的锁更少。
- 最好不要用 (SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE)。
- 如果上述都无法解决问题，那么尝试使用 lock tables t1, t2, t3 锁多张表
可以通过以下三个语句来查询被打开的表，正在执行的任务列表和开启的事务
show OPEN TABLES where In_use > 0;
show processlist; -- kill杀死进程id（id列）
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
-- kill杀死进程id（trx_mysql_thread_id列）
