如何模拟并发减库存导致的慢sql

完整的截图中有10个同样的update sql,最长的有56秒
这条update sql对应的业务逻辑是这样的
用户中奖后对应奖品库存减一
而我在本地想模拟出这种情况 确定原因是什么以及该如何优化。首先想到的原因就是高并发导致的锁竞争， 于是基于此思路，我将最大连接数改成了10
show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 10 |
+-----------------+-------+
然后启动了100个线程并发执行减库存sql 很快就全部执行完了 500个线程并发执行也不足一秒啊
100 threads concurrent update stock took time: 168(ms)
500 threads concurrent update stock took time: 504(ms)

编写你的脚本

使用JMeter进行本地测试

BlazeMeter沙箱测试

使用一个控制台和一个引擎设置Users-per-Engine的数量

设置并测试你的集合 (1个控制台和10-14 引擎)

使用 Master / Slave 特性来达成你的最大CC目标

高并发量网站解决方案 一个小型的网站，可以使用最简单的html静态页面就实现了，配合一些达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单。随着互联网业务的不断丰富，网站相关的技术经过这些年

---