背景
之前我参与过一个项目，在项目初期，我们是没有将读写表分离的，而是基于一个主库完成
读写操作。在业务量逐渐增大的时候，我们偶尔会收到系统的异常报警信息，DBA 通知我
们数据库出现了死锁异常。
按理说业务开始是比较简单的，就是新增订单、修改订单、查询订单等操作，那为什么会出
现死锁呢？经过日志分析，我们发现是作为幂等性校验的一张表经常出现死锁异常。我们和
DBA 讨论之后，初步怀疑是索引导致的死锁问题。后来我们在开发环境中模拟了相关操
作，果然重现了该死锁异常。
生成问题重现
接下来我们就通过实战来重现下该业务死锁异常。首先，创建一张订单记录表，该表主要用
于校验订单重复创建：
sql
CREATE TABLE `order_record` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`order_no` int(11) DEFAULT NULL,
`status` int(4) DEFAULT NULL,
`create_date` datetime(0) DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE,
INDEX `idx_order_status`(`order_no`,`status`) USING BTREE
) ENGINE = InnoDB为了能重现该问题，我们先将事务设置为手动提交。这里要注意一下，MySQL 数据库和
Oracle 提交事务不太一样，MySQL 数据库默认情况下是自动提交事务，我们可以通过以
下命令行查看自动提交事务是否开启：
sql
mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | ON |
+---------------+-------+
1 row in set (0.01 sec)下面就操作吧，先将 MySQL 数据库的事务提交设置为手动提交，通过以下命令行可以关
闭自动提交事务：
sql
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)订单在做幂等性校验时，先是通过订单号检查订单是否存在，如果不存在则新增订单记录。
知道具体的逻辑之后，我们再来模拟创建产生死锁的运行 SQL 语句。首先，我们模拟新建
两个订单，并按照以下顺序执行幂等性校验 SQL 语句（垂直方向代表执行的时间顺序）：
此时，我们会发现两个事务已经进入死锁状态。我们可以在 information_schema 数据库
中查询到具体的死锁情况，如下图所示：
看到这，你可能会想， 为什么 SELECT 要加 for update 排他锁，而不是使用共享锁呢？ 试
想下，如果是两个订单号一样的请求同时进来，就有可能出现幻读。也就是说，一开始事务
A 中的查询没有该订单号，后来事务 B 新增了一个该订单号的记录，此时事务 A 再新增一
条该订单号记录，就会创建重复的订单记录。面对这种情况，我们可以使用锁间隙算法来防
止幻读。
避免死锁的措施
知道了死锁问题源自哪儿，就可以找到合适的方法来避免它了。
避免死锁最直观的方法就是在两个事务相互等待时，当一个事务的等待时间超过设置的某一
阈值，就对这个事务进行回滚，另一个事务就可以继续执行了。这种方法简单有效，在
InnoDB 中，参数 innodb_lock_wait_timeout 是用来设置超时时间的。
另外，我们还可以将 order_no 列设置为唯一索引列。虽然不能防止幻读，但我们可以利用
它的唯一性来保证订单记录不重复创建，这种方式唯一的缺点就是当遇到重复创建订单时会
抛出异常。
我们还可以使用其它的方式来代替数据库实现幂等性校验。例如，使用 Redis 以及
ZooKeeper 来实现，运行效率比数据库更佳。