避免死锁的建议

• 正确使用读操作语句
经过之前文章介绍，我们知道一般的快照读是不会给数据表任何锁的。那么这些快照读操作也就不涉及到参与任何锁等待的情况。那么对于类似insert…select这样需要做当前读操作的语句（但又不是必须进行当前读的操作），笔者的建议是尽可能避免使用它们，如果非要进行也最好放到数据库操作的非高峰期进行（例如晚间）。
• 基于索引进行写操作，避免基于表扫描（聚集索引扫描）进行写操作
基于索引进行写操作的目的是保证一个写操作性质的事务中，被锁住的索引和需要请求的锁定资源被控制在最小范围内。而避免使用表锁的原因是保证一个写操作性质的事务中，不会额外锁住完全不需要的索引资源或者抢占完全不需要的索引资源。表锁虽然不会直接导致死锁，但是由于表锁的工作方式，导致它成为死锁原因的几率增大了。
• 避免索引失效
使用索引一定要注意索引字段的类型，例如当字段是一个varchar类型，赋值却是一个int类型，就会导致索引失效。如下所示：
explain select * from myuser where user_name = 1

user_name 字段的类型是varchar，该字段建立了一个非唯一键索引

但是以上语句在使用字段进行检索时，却使用了一个int作为条件值。

通过MySQL的执行计划可以看到，InnoDB引擎在执行查询时并未使用索引，而是走的全表扫描

+—-+————-+——-+——+—————+—–+——+————-+
| id | select_type | table | type | possible_keys | key | rows | Extra |
+—-+————-+——-+——+—————+—–+——+————-+
| 1 | SIMPLE | myuser| ALL | name_index | | 13 | Using where |

• 关键业务的delete、update语句应该使用执行计划进行审核：从MySQL version 5.6 版本开始，MySQL中的执行计划功能已经支持对delete、update语句进行执行过程分析了。如果需要执行比较复杂和相关操作或者关键业务的写操作，都应该首先在执行计划中观察其运行方式。后文我们马上开始执行计划的讲解。