冻结库存，性能翻8倍的背后原理

#技术 #mysql

背景如下

双十一压测，库存服务冻结场景性能不忍直视，QPS 令人汗颜，相比于其他的接口性能，差的不止一点半点。 sql如下

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 没有开启，则该参数也不会开启。

思考

如果问题发生，如何进行思考？

表象是这个表象，要通过表象查看事物底层原因问题
技术底层知识，必不可少，比如 io，mysql底层，往往一些常规的措施，已经知道的，大家都已经知道了，而真正卓越优秀突出的，就在在往前的那么一丁点上。
多扩展自己的知识面，触类旁通，这样有更高的眼界和思维，更多方面的思考。
一个人，难以想明白，集合大家的思路，一起进行脑暴