問(wèn)題描述

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

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

用戶(hù)中獎(jiǎng)后對(duì)應(yīng)獎(jiǎng)品庫(kù)存減一

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

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

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

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

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

問(wèn)題解答

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

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