問題描述

DBA給了我如下一些慢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)

那么該如何能模擬出線上的這種情況呢？

問題解答

流量復制，類似于這種 HTTP 流量復制工具：Gor Go，比較高大上;

自己模擬，使用工具如 Locust 來自定義請求，以實現模擬實際場景。案例有基于Locust、Tsung的百萬并發秒殺壓測案例