問題描述

DBA給了我如下一些慢sql的截圖 希望我能優(yōu)化一下完整的截圖中有10個(gè)同樣的update sql,最長的有56秒

這條update sql對應(yīng)的業(yè)務(wù)邏輯是這樣的

用戶中獎(jiǎng)后對應(yīng)獎(jiǎng)品庫存減一

而我在本地想模擬出這種情況 確定原因是什么以及該如何優(yōu)化。首先想到的原因就是高并發(fā)導(dǎo)致的鎖競爭， 于是基于此思路，我將最大連接數(shù)改成了10

show variables like ’max_connections’;+-----------------+-------+| Variable_name | Value |+-----------------+-------+| max_connections | 10 |+-----------------+-------+

然后啟動(dòng)了100個(gè)線程并發(fā)執(zhí)行減庫存sql 很快就全部執(zhí)行完了 500個(gè)線程并發(fā)執(zhí)行也不足一秒啊

100 threads concurrent update stock took time: 168(ms)500 threads concurrent update stock took time: 504(ms)

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

問題解答

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

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