冻结库存，性能翻8倍的背后原理
#技术 #mysql
背景如下
双十一压测，库存服务冻结场景性能 不忍直视，QPS 令人汗颜，相比于其他的接口性能，差的不止一点半点。 sql如下
update stockset frozen_num = frozen_num + #{num}where stock_num - frozen_num - #{num}> 0and id = #{id}
单数据，循环去压
最终是由DBA从db 的层面，去解决了这个问题。
当时业务侧，通过代码进行压测，单条性能只能达到1000+ 一点 但是dba 单压sql ，能达到1.2 w左右的QPS，这样的情况。
如何会有这么大的一个差别。
解决思路
通过以上的一个表现，去进行了一些思考。
- 业务侧的路由算法导致
路由一般都是很简单的基本算法，不会有太大的性能损耗，且是倍数的处理。
- 事务问题导致： 的确，带事务比不带事务，性能要高不少，但是也是有限，依旧达不到DBA的压测水准。
- 业务侧 + db 侧 两方面处理 目前DB 版本为 mysql 5.7.x 最后调整了这2个参数
这2个基于mysql 5.7 新增的参数设置，通过设置该值，压测性能 也能到达了 8000
但是，究竟原理是为什么呢？
1.： ** binlog_group_commit_sync_delay
全局动态变量，单位微妙，默认0，范围：0～1000000（1秒）。 表示binlog提交后等待延迟多少时间再同步到磁盘，默认0，不延迟。设置延迟可以让多个事务在用一时刻提交，提高binlog组提交的并发数和效率，提高slave的吞吐量。 2： binlog_group_commit_sync_no_delay_count
全局动态变量，单位个数，默认0，范围：0～1000000。
表示等待延迟提交的最大事务数，如果上面参数的时间没到，但事务数到了，则直接同步到磁盘。若 binlog_group_commit_sync_delay 没有开启，则该参数也不会开启。
思考
如果问题发生，如何进行思考？
