本文记录下关于MySQL优化的学习和一点点思考。
案例
一个并发比较大的下单接口；
包括
- step1 扣减商品库存
- step2 生成订单数据
- step3 记录操作记录
伪代码如下，底层使用的是MySQL数据库，单体服务(你问我为什么单体，案例需要啦)。
提问：暂时不考虑分布式锁、缓存、异步等使用场景，下面的代码执行步骤有没有值得优化的点？
@Transactional(rollbackFor = Exception.class)
public void createOrder(Entity param){
...校验等
//step1 扣减商品库存
//update products set stock = stock where sku_id = XXX
deductStock(param);
//step2 生成订单数据
//insert into order XXXXXX
createOrder(param);
//step3 记录操作记录
//insert into operation_records XXX
recordOperation(param);
...
}
上述代码做了哪些事，开启了事务
更新了一个个表：库存表库存分
插入了两条数据：用户订单表，用户操作记录
对于当前的业务，上述代码的DB执行流程是没有问题的，
但是朋友，我们是要有梦想滴，CRUD BOY不是我们的终点，我们的目标是星辰大海。
来，键盘给你，优化下。
优化思路
正常业务情况下，上述代码没毛病，开启事务，库存更新语句会加上行锁，插入语句可能会加上插入意向锁等。
我们重点来关注下 更新语句的行锁，并发高的情况下，同一种库存商品数据是根据sku_id来更新，存在激烈的行锁竞争抢占的问题。
来回忆一下，MySQL事务开启后，是什么时候开始给库存加行锁的？
事务开启就加行锁？ 错。
是在执行更新语句的时候加锁的，上述的step1。
那么解锁是什么时候呢？
当然是事务提交的时候。
那么对于案例中的语句来说，products表的sku_id = XXX这行数据的行锁，将从step1开始锁定，直到createOrder()方法执行完毕才会解锁。
对于其他的创建订单请求，热点商品，相同的sku_id，同时执行这行代码的时候，只能等待。
这样分析可以发现，持有锁的时间太长了。
没错，是时间太长了，换个场景，或许我会欣喜若狂，彷佛得到了认可，
但此时此刻，这并不是我想要的。
那么，是否可以将更新库存的语句放到最后呢，step1 变成step3，这样对一一次创建订单的请求，加锁的时长会大大减少，并发度会提升。
@Transactional(rollbackFor = Exception.class)
public void createOrder(Entity param){
...校验等
//step1 生成订单数据
//insert into order XXXXXX
createOrder(param);
//step2 记录操作记录
//insert into operation_records XXX
recordOperation(param);
//step3 扣减商品库存
//update products set stock = stock where sku_id = XXX
deductStock(param);
...
}
这样的优化虽不起眼，但是架不住积少成多，从细节处着手，才能仰望星空。
这样才是泰裤辣！
死锁的一些记录笔记
继续讨论下，上述代码没有问题了，但是
职业生涯中，我并没有真正的面对过MySQL的死锁，很幸运也很不幸，无需面对老大难的风险，但也没有获得实操的经验。
死锁的产生及竞态条件不再赘述。
最接近死锁的一次，还是刚工作的时候在一家保险公司，我还是nobody，当然了现在也还是nobody。
大约记得夜里的批处理更新账户信息，以及客户投保时，都需要保险账户总表及账户明细表更新，批处理和客户投保的请求互相竞争对方持有的锁，导致死锁，疯狂报警，处理方案则是DBA大半夜爬起来 kill掉其中一个session，解除死锁。
很明显上述处理的方案是不可持续的。
完全避免死锁不太现实，我们需要做的是尽可能减少死锁发生的概率。
MySQL给我们提供了两种方案
- 互相等待锁释放，直至超时，通过
innodb_lock_wait_timeout来设置 - 死锁检测，
innodb_deadlock_detect设置为on（8.0之后版本提供）
第一种策略，我们固然可以设置很短的超时时间，但是对于慢SQL来说很容易误伤。
所以一般会有第二种方案，超时检测。
MySQL会自动查询是否存在连接相互等待获取对方连接的情况，如果存在，会回滚其中一个事务来打破死锁。
但是高并发情况下，比如上述的案例接口，死锁检测会影响到MySQL执行速度和效率，我们就只能通过第一这种方案来等待超时释放。
热点行问题
正如我们上面讨论的，案例中的某个热门产品的库存对于MySQL来说就是热点行，会存在频繁的锁竞争及死锁等问题，会导致性能下降，MySQL本身也没有更好的方案来避免。
我们考虑下从业务层来解决这个问题。
- redis预扣减
使用redis缓存热点商品，借助redis的高性能、高并发特性，承担大部分的请求压力。
但是redis会增加复杂度，可能会带来数据不一致的情况，例如超卖和少卖。
- 库存拆分
往往库存只有一条数据，作为共享资源，为了保证安全，MySQL会对这条数据加锁，请求只能排一条长队等待锁的释放，如果我们把这条数据拆分成多条，10条数据，20条数据，性能的提升是可以预见的，大量请求的锁竞争可被分散在多条数据上，请求的耗时根据拆分的力度逐渐降低。
拆分缺点也很明显，对于拆分后的数据，某条库存用完了怎么办，怎么判断库存超卖不超卖，以及库存数据的增加维护等等等，系统复杂度会提升。
- 请求合并
对于反馈需要及时的电商场景，请求合并并不一定适合，但是对于实时性没那么强的业务场景，比如说银行或者保险的热点账户，多个账户变动请求同时变更同一个账户，我们可以在1s、5s或者更长一段时间内将这段时间的多个请求在内存中计算合并后，再去更新数据库，可以大大降低数据库的压力。
- 更新转插入
这种方式也是针对异步场景 UPDATE语句转INSERT语句，原来更新一条数据，改为插入单独的一个明细表，通过异步的方式将明细表进行汇总计算，再合并到原数据中。
这么一想设计思想是否和MySQL redo log的使用方式比较接近了，先顺序写磁盘，然后异步写入MySQL数据表中。
很多设计思想都是一致的，无非是实现的区别
理论上我们上述说的方案，也都可以通过MySQL进行改造，比如请求合并，改为在MySQL层对相同的SQL语句（这里的相同指更新逻辑基本一致）进行合并。
