這份指南的初稿我拿到的時候方案編號后面跟著一串長長的時間戳估計是文檔系統(tǒng)自動追加上去的批次號。真正值得關(guān)注的是里面列出的每一個步驟有沒有經(jīng)過真實項目的驗證而不是編號本身有多整齊。干性能和穩(wěn)定性相關(guān)的工作這些年我處理過的高頻問題幾乎都長一個樣平時系統(tǒng)跑得好好的一到業(yè)務(wù)高峰就翻車單機(jī)壓測數(shù)據(jù)漂亮得能發(fā)朋友圈一上真實場景就露餡。壓力測試和性能調(diào)優(yōu)從來不是“拉一個工具跑十分鐘”就能交差的事。這篇內(nèi)容按我自己實際操作時的順序來寫覆蓋工具選型、JMeter怎么做、報告怎么讀、MySQL和系統(tǒng)層怎么調(diào)以及多輪壓測怎么沉淀成團(tuán)隊可復(fù)用的容量基線。適合剛剛接手壓測任務(wù)、或者團(tuán)隊正準(zhǔn)備引入一套規(guī)范化壓測流程的讀者。我會把每一步背后的取舍理由說清楚而不是只甩參數(shù)和截圖。1. 先統(tǒng)一認(rèn)知壓測不是在找系統(tǒng)的死法而是在找安全邊界1.1 先把壓測目標(biāo)拆成三類容量測試、并發(fā)測試與穩(wěn)定性測試很多人一接到壓測任務(wù)第一反應(yīng)就是“把并發(fā)數(shù)調(diào)大看到系統(tǒng)報錯為止”。這種想法需要糾正一下。壓力測試本身不是目的搞清楚系統(tǒng)在什么條件下還能安全服務(wù)才是目的。我習(xí)慣把壓測先拆成三個方向容量測試系統(tǒng)最多能支撐多大的業(yè)務(wù)量比如每秒處理多少訂單、多少查詢。這個結(jié)果直接決定了要不要擴(kuò)容、要不要限流。并發(fā)測試同一時刻有多少用戶在執(zhí)行操作還不出錯。這里的“操作”往往是復(fù)合鏈路比如登錄、查列表、提交訂單。穩(wěn)定性測試系統(tǒng)在接近容量上限的負(fù)載下持續(xù)跑一段時間比如4小時、8小時、24小時觀察內(nèi)存、連接數(shù)、慢請求是否有累積性劣化。這三類測試的腳本設(shè)計、指標(biāo)目標(biāo)、執(zhí)行時長完全不同。可實際工作中遇到最多的情況是一把腳本從頭用到尾線程數(shù)調(diào)到300跑完看聚合報告得出一個“系統(tǒng)能扛300并發(fā)”的結(jié)論。這個結(jié)論如果是容量測試那并發(fā)和穩(wěn)定性都沒驗證到如果是并發(fā)測試那持續(xù)時長又不夠結(jié)論可信度很低。所以拿到壓測需求時第一件事不是開JMeter而是問清楚這次到底要回答哪類問題。1.2 被測環(huán)境與數(shù)據(jù)規(guī)模的邊界沒有基線就沒有結(jié)論壓測結(jié)果是否可信很大程度上取決于被測環(huán)境和數(shù)據(jù)規(guī)模是否接近真實。這里的坑非常隱蔽。首先是環(huán)境。我見過不少團(tuán)隊直接拿生產(chǎn)環(huán)境的一個節(jié)點來壓測理由是“機(jī)器配置和生產(chǎn)一致結(jié)果最準(zhǔn)確”。這種做法壞處很大壓測流量會污染線上數(shù)據(jù)比如產(chǎn)生大量測試訂單、測試緩存而生產(chǎn)環(huán)境的流量本身就在波動壓測結(jié)果會和真實業(yè)務(wù)流量摻雜在一起最終報告根本沒法解讀。正確的做法是準(zhǔn)備一套獨立的壓測環(huán)境至少要做到應(yīng)用版本與生產(chǎn)一致數(shù)據(jù)庫結(jié)構(gòu)一致中間件版本一致。其次是數(shù)據(jù)規(guī)模。這一點被忽略的頻率相當(dāng)高。一個只有1萬條記錄的訂單表和1000萬條記錄的訂單表查詢計劃可能完全不同。1萬條數(shù)據(jù)時全表掃描也就幾毫秒1000萬條數(shù)據(jù)時全表掃描可能就是幾百毫秒。很多壓測報告看起來“性能很好”其實就是數(shù)據(jù)量太少索引失效的問題完全沒暴露出來。壓測數(shù)據(jù)建議至少做到生產(chǎn)數(shù)據(jù)量的三分之一左右并且分布規(guī)律要接近真實情況比如買家ID不是只集中在幾個號碼段。1.3 容易被忽略的前提壓測流量要接近真實請求結(jié)構(gòu)還有一個常見誤區(qū)就是壓測時只壓一個最簡單的接口。比如團(tuán)隊要上線一個新首頁壓測腳本里只放了首頁HTML請求沒帶靜態(tài)資源、沒帶登錄態(tài)、沒帶用戶參數(shù)。這類壓測跑出來的數(shù)據(jù)只能證明一個空骨架接口的性能和真實用戶訪問時的請求結(jié)構(gòu)沒有對應(yīng)關(guān)系。真實的用戶流量有幾個特征有一部分是首次訪問沒有登錄態(tài)有一部分是登錄后帶Cookie請求參數(shù)中用戶ID和商品ID分布很散讀寫比例大概在8比2或者7比3。壓測腳本越接近這個結(jié)構(gòu)結(jié)果越有參考價值。所以我在設(shè)計腳本時至少會疊加三塊內(nèi)容登錄態(tài)Cookie或Token、參數(shù)化數(shù)據(jù)用戶ID、商品ID、訂單號從CSV里取、混合接口比例查詢?yōu)橹鳌懭胝忌俨糠帧e嫌麻煩這一步偷懶后面所有結(jié)論都要打折扣。2. 工具選型的取舍JMeter、網(wǎng)頁版壓測平臺和Coze壓測模塊各自解決什么問題2.1 JMeter的定位腳本自由度高適合協(xié)議級復(fù)合場景JMeter是我用得最多、也最愿意推薦給團(tuán)隊的主力工具。原因有三點。第一它開源免費Apache社區(qū)維護(hù)資料非常多遇到問題基本都能搜到答案。第二它覆蓋的協(xié)議廣HTTP、HTTPS、JDBC、TCP、FTP都有現(xiàn)成采樣器對于絕大多數(shù)Web應(yīng)用和微服務(wù)接口來說夠用了。第三腳本可以參數(shù)化、可以加斷言、可以分布式擴(kuò)展能應(yīng)對從簡單接口到復(fù)雜鏈路的壓測需求。JMeter的缺點也很明顯上手需要一點時間界面比較“工程化”不像商業(yè)工具那么好看而且它本質(zhì)上是個協(xié)議級壓測工具模擬的是“請求是否按預(yù)期返回”對瀏覽器端渲染、JS執(zhí)行這類前端交互無能為力。如果業(yè)務(wù)性能瓶頸在前端渲染JMeter測不出來得配合瀏覽器性能工具一起看。2.2 網(wǎng)頁版壓測平臺的優(yōu)勢與限制方便但容易只測了個表面網(wǎng)頁版壓測平臺也就是常說的在線壓力測試服務(wù)這類工具這兩年越來越多。它們的核心優(yōu)勢是零安裝注冊賬號、填寫被測地址、選擇并發(fā)數(shù)和時長點開始就能看到一份漂亮的報表。非常適合快速驗證某個接口的極限吞吐比如“新上的活動頁能不能扛住秒殺流量”。但我對這類工具一直保留態(tài)度原因也很實在壓力節(jié)點通常在云端如果你要測的是內(nèi)網(wǎng)系統(tǒng)或者帶有敏感數(shù)據(jù)的接口流量根本進(jìn)不來就算被測系統(tǒng)部署在公網(wǎng)數(shù)據(jù)安全也是一個繞不開的問題很多企業(yè)不敢把生產(chǎn)環(huán)境的請求結(jié)構(gòu)完整發(fā)給第三方平臺另外這類平臺的策略比較固定想精細(xì)控制每個接口的請求比例、想加復(fù)雜的斷言邏輯就比較受限。我的建議是網(wǎng)頁版平臺適合做初步摸底不適合作為正式容量評估和性能調(diào)優(yōu)的依據(jù)。2.3 Coze壓測模塊面向AI Bot對話場景的補(bǔ)充手段最近這一兩年AI Bot和Agent類應(yīng)用越來越多傳統(tǒng)協(xié)議級壓測工具在面會話型應(yīng)用時有點使不上勁。原因在于Bot對話場景不只是一個HTTP請求它通常包含多輪上下文、異步響應(yīng)、插件工具調(diào)用響應(yīng)時間和用戶感知質(zhì)量強(qiáng)相關(guān)。Coze這類AI應(yīng)用構(gòu)建平臺內(nèi)置了壓力測試模塊可以模擬多個用戶同時和Bot對話并觀察平均響應(yīng)時間、成功率和并發(fā)處理能力。這個模塊的價值在于它理解Bot會話的結(jié)構(gòu)不需要自己手工組裝多輪對話請求。如果你做的是傳統(tǒng)Web應(yīng)用用不上它但如果團(tuán)隊在做一個基于Coze的AI客服、AI助手那這個模塊就能省很多事。它在整套壓測體系里屬于面向會話場景的一個補(bǔ)充手段和JMeter處理協(xié)議級并發(fā)是互補(bǔ)關(guān)系。2.4 現(xiàn)實中的工具選型參考工具類型適用場景學(xué)習(xí)成本靈活度主要限制JMeterWeb接口、微服務(wù)、復(fù)合業(yè)務(wù)鏈路、分布式壓測中高需配置JVM和插件界面偏工程化網(wǎng)頁版壓測平臺公網(wǎng)接口快速摸底、活動頁面極限測試低低無法測內(nèi)網(wǎng)數(shù)據(jù)安全受限Coze壓測模塊AI Bot、Agent多輪對話場景低中局限于Coze平臺內(nèi)構(gòu)建的應(yīng)用我的選擇標(biāo)準(zhǔn)很簡單能內(nèi)網(wǎng)部署、腳本可控、數(shù)據(jù)不出域的優(yōu)先JMeter需要云上大規(guī)模分布式壓力且被測系統(tǒng)本身在公網(wǎng)可考慮網(wǎng)頁版平臺做補(bǔ)充AI Bot場景單獨用Coze模塊驗證。三個工具不沖突根據(jù)業(yè)務(wù)形態(tài)選就行。3. JMeter從腳本到報告線程組、參數(shù)化與非GUI運行的關(guān)鍵細(xì)節(jié)3.1 腳本準(zhǔn)備線程組參數(shù)到底怎么填才合理第一次打開JMeter的“線程組”面板很多人會被一堆參數(shù)嚇住線程數(shù)、Ramp-Up Period、循環(huán)次數(shù)、調(diào)度器。我逐個說明。線程數(shù)就是模擬的并發(fā)用戶數(shù)也是最常被拿來“拍腦袋”填的值。正確做法是從業(yè)務(wù)預(yù)期反推假設(shè)線上平均每天100萬請求高峰集中在2小時粗略估算高峰QPS是1000000除以7200約等于139。如果要模擬這個負(fù)載結(jié)合平均響應(yīng)時間200毫秒來計算并發(fā)線程數(shù)大約等于QPS乘以平均響應(yīng)時間也就是139乘以0.2約等于28。這是個粗略估算實際跑出來會上下浮動但至少不是憑空填300。Ramp-Up Period是JMeter啟動線程的耗時。默認(rèn)填0表示所有線程同時啟動瞬間把壓力打滿。真實驗場景里用戶是逐漸涌進(jìn)來的不是槍響那一刻同時點鼠標(biāo)。所以我一般按“線程數(shù)除以5”來填啟動秒數(shù)比如100個線程就填20秒讓壓力平滑上升。有一點要注意如果你測的就是秒殺搶購那種瞬時沖擊場景Ramp-Up確實應(yīng)該填0這取決于測試目標(biāo)而不是固定喜好。循環(huán)次數(shù)是每個線程執(zhí)行腳本的次數(shù)。如果填1跑完即止如果勾選“永遠(yuǎn)”腳本就會一直跑直到手動停止。這塊我踩過坑有一次團(tuán)隊做長穩(wěn)測試循環(huán)次數(shù)沒設(shè)置只勾了“永遠(yuǎn)”結(jié)果聚合報告里的Samples數(shù)瘋漲跑了快一個小時才被發(fā)現(xiàn)。現(xiàn)在我的習(xí)慣是容量測試用固定循環(huán)次數(shù)通過總請求數(shù)控制時長穩(wěn)定性測試才用“永遠(yuǎn)”配合調(diào)度器設(shè)置持續(xù)時間。3.2 CSV參數(shù)化讓壓測流量接近真實用戶而不是一個賬號打到死參數(shù)化是壓測腳本里最容易被偷懶的地方也是壓測結(jié)果可信度的分水嶺。不參數(shù)化的腳本長這樣100個線程每個請求都帶同一個用戶ID和同一個商品ID。這種流量在真實線上是不存在的。我通常用CSV Data Set Config來做參數(shù)化。準(zhǔn)備一個CSV文件里面有幾百上千行用戶數(shù)據(jù)包括user_id、token、商品ID等字段然后在請求參數(shù)里引用變量。配置時注意“Sharing mode”選擇“Current thread”每個線程循環(huán)時取不同行的數(shù)據(jù)這樣更接近真實用戶行為。參數(shù)化不只是讓數(shù)據(jù)好看。它直接影響測試結(jié)論的準(zhǔn)確性如果不參數(shù)化所有請求都命中同一個Redis緩存鍵壓出來的TPS虛高上線后真實用戶一多緩存鍵分散了性能立刻打回原形。反過來如果參數(shù)化做得太好每個請求都是全新用戶也未必符合業(yè)務(wù)因為真實場景大部分用戶是重復(fù)訪問的。讓參數(shù)在有限集合里循環(huán)比隨便搞十萬個隨機(jī)參數(shù)更真實。3.3 斷言、監(jiān)聽器與非GUI運行結(jié)果可信度從哪里來壓測腳本里一定要加斷言這是很多新手容易忽略的。不加斷言服務(wù)器返回500也算“請求完成”聚合報告里Events看著幾千條實際上全是錯誤。最簡單的方式是用“響應(yīng)斷言”檢查響應(yīng)代碼是否等于200條件允許的話檢查響應(yīng)體里是否包含某業(yè)務(wù)關(guān)鍵字。加斷言會帶來少量性能開銷但相比結(jié)論可信度的價值這點開銷可以忽略。監(jiān)聽器方面我的習(xí)慣是開發(fā)和調(diào)試腳本時打開“查看結(jié)果樹”真正跑壓測時只保留“聚合報告”和必要的后端監(jiān)聽器。原因很直接查看結(jié)果樹會把每一個請求的完整響應(yīng)都存在內(nèi)存里壓測機(jī)本身內(nèi)存有限跑著跑著就OOM或GC嚴(yán)重壓測機(jī)自己先掛了報告自然是錯的。JMeter的GUI模式也一樣界面刷新、曲線繪制都會消耗CPU和內(nèi)存。正式壓測要這樣跑jmeter -n -t test_plan.jmx -l result.jtl -e -o report_dir-n表示非GUI模式-t指定腳本-l輸出原始結(jié)果數(shù)據(jù)-e和-o用來生成HTML格式的匯總報告。用命令行跑壓測機(jī)資源才能全部用在發(fā)起請求上。這也是壓測報告中環(huán)境描述里必須寫清楚的一條是否使用了非GUI模式。3.4 分布式壓測什么時候需要配多少臺壓測機(jī)才合適單臺壓測機(jī)有上限。當(dāng)需要模擬的并發(fā)數(shù)很高或者被測系統(tǒng)的帶寬、連接數(shù)已經(jīng)把單臺壓測機(jī)資源吃滿時就要考慮分布式壓測。JMeter的分布式模式是Master加多臺SlaveMaster負(fù)責(zé)統(tǒng)一調(diào)度和收集結(jié)果Slave負(fù)責(zé)實際發(fā)起請求。這里面有幾個我自己總結(jié)的注意點。第一Slave和Master的JMeter版本要一致不然結(jié)果匯總可能出問題。第二各臺壓測機(jī)器建議在同一內(nèi)網(wǎng)里跨地域的Slave會因為網(wǎng)絡(luò)延遲干擾壓測結(jié)果。第三Master機(jī)器需要足夠的線程來處理各個Slave回傳的結(jié)果數(shù)據(jù)一般一臺普通的Master扛幾百臺Slave的匯總沒什么問題但Master千萬別再去承擔(dān)實際發(fā)壓的任務(wù)。第四壓測機(jī)之間做好時間同步否則長穩(wěn)測試的時間維度和報告對不上。分布式不是萬金油能單機(jī)跑完就不上分布式多一臺機(jī)器就多一份排查成本。4. 報告讀法讓TPS、響應(yīng)時間、R23與資源指標(biāo)互相印證4.1 核心指標(biāo)怎么聯(lián)動看吞吐量、響應(yīng)時間、錯誤率與資源占用壓測報告跑出來別急著看平均值。聚合報告里的字段不少但要抓的是四類吞吐量、響應(yīng)時間、錯誤率、資源使用率。吞吐量是系統(tǒng)每秒能處理的請求數(shù)或事務(wù)數(shù)單位可能是/sec。響應(yīng)時間字段里Average是平均響應(yīng)時間這個值很騙人——少量極快請求會把平均值拉低。更值得看的是P90、P95、P99這些百分位值P99能反映最差一批用戶的體驗。錯誤率來自斷言代表了請求不符合預(yù)期的比例不能單看HTTP響應(yīng)碼業(yè)務(wù)邏輯錯誤往往響應(yīng)碼也是200。更重要的是把這幾個指標(biāo)和資源使用率放在一起看而不是各看各的。舉個例子壓測到300并發(fā)時TPS不再上漲但CPU利用率只有30%。這說明瓶頸根本不在CPU這時候去調(diào)CPU相關(guān)參數(shù)就是在浪費精力真正的原因可能是數(shù)據(jù)庫連接池滿了或者Redis訪問鏈路上有鎖競爭。相反如果CPU已經(jīng)90%以上TPS還上不去那說明計算本身成為了瓶頸該查代碼、查SQL了。報告里的TPS只是現(xiàn)象資源指標(biāo)是線索兩者對不上結(jié)論就不成立。4.2 單機(jī)硬件壓力測試R23這類工具如何幫忙做基準(zhǔn)對照服務(wù)端壓測聊得好好的為什么突然要提R23因為有些性能問題根本不在代碼而在硬件本身特別是CPU的散熱和降頻行為。Cinebench R23是常見的單機(jī)CPU壓力測試工具它會把CPU跑到接近滿載狀態(tài)并持續(xù)一段時間。很多人以為它只是跑分工具其實它還有一個用處驗證機(jī)器在長時間高負(fù)載下會不會因為散熱不足而降頻。我之前遇到過一種情況長穩(wěn)測試跑了3個小時后TPS緩慢往下掉業(yè)務(wù)代碼改來改去沒效果最后發(fā)現(xiàn)是機(jī)柜里那臺服務(wù)器的CPU溫度到了閾值頻率從3.2GHz降到了2.4GHz。硬件一降頻業(yè)務(wù)性能自然就縮水。所以我的建議是在正式的容量測試之前先在被測機(jī)器上跑一輪R23確認(rèn)它在持續(xù)滿載下能保持穩(wěn)定頻率。這樣一來壓測報告里的任何性能波動至少可以先排除“機(jī)器本身扛不住”這個變量。R23的定位是單機(jī)硬件基準(zhǔn)和JMeter這類業(yè)務(wù)級壓力測試不是一回事但兩者配合能讓壓測結(jié)論更干凈。4.3 瓶頸定位的排查順序錯誤優(yōu)先、資源其次、慢請求兜底拿到一次失敗的壓測結(jié)果比如TPS上不去、錯誤率飆升按什么順序排查是有講究的。我的排查鏈路固定是先看錯誤類型再看系統(tǒng)資源最后看慢請求分布。先看錯誤類型。響應(yīng)結(jié)果是超時、連接拒絕、5xx還是斷言失敗超時通常意味著系統(tǒng)處理不過來連接拒絕可能是線程池滿了5xx往往是應(yīng)用異常。這一步能圈定問題所在的大致層級。再看系統(tǒng)資源。用top、free、iostat、vmstat這些命令看清楚CPU、內(nèi)存、磁盤I/O和網(wǎng)絡(luò)占用。如果CPU打滿問題大概率在計算如果內(nèi)存持續(xù)增長可能內(nèi)存泄漏如果磁盤I/O超高慢SQL或日志刷屏是主要嫌疑。最后看慢請求的時間分布。P99在哪個時間段突然惡化對應(yīng)當(dāng)時壓測并發(fā)是多少以及系統(tǒng)當(dāng)時是什么狀態(tài)。這樣能判斷是積累到某個閾值后突然劣化還是從某個并發(fā)開始就線性惡化。這套順序每次都能幫我省掉大量無效排查時間不按順序亂翻往往會繞遠(yuǎn)路。4.4 一個讓我印象深刻的案例壓測數(shù)據(jù)正常但線上并發(fā)一高就崩講一個實際案例。之前有個團(tuán)隊做了一次壓測報告顯示TPS能達(dá)到3000錯誤率不到0.1%數(shù)據(jù)相當(dāng)漂亮。結(jié)果上線后白天業(yè)務(wù)高峰并發(fā)只有50左右系統(tǒng)就開始出現(xiàn)超時和報錯。團(tuán)隊很困惑把壓測報告翻來覆去看也沒發(fā)現(xiàn)問題。后來排查發(fā)現(xiàn)壓測腳本里的參數(shù)化做得太潦草用戶ID只準(zhǔn)備了幾十個而且都是從線上日志里抽出來的活躍用戶這些用戶的Token在Redis緩存里都是熱數(shù)據(jù)。壓測時所有請求都命中緩存數(shù)據(jù)庫幾乎沒壓力。到了線上真實用戶分布在幾百萬ID里大部分請求需要回源到數(shù)據(jù)庫數(shù)據(jù)庫的慢查詢立刻暴露了出來。這就是經(jīng)典的“參數(shù)化不足掩蓋真實瓶頸”案例。壓測腳本里的用戶分布、數(shù)據(jù)熱度直接決定了壓測結(jié)論和真實線上體驗之間的差距。5. MySQL與系統(tǒng)層的調(diào)優(yōu)順序慢查詢優(yōu)先參數(shù)改動講究唯一變量5.1 慢查詢?nèi)罩臼荕ySQL調(diào)優(yōu)的第一現(xiàn)場要說性能調(diào)優(yōu)從數(shù)據(jù)庫入手是收益最大的方向之一而數(shù)據(jù)庫調(diào)優(yōu)的第一步不是改參數(shù)是開慢查詢?nèi)罩尽ySQL的慢查詢?nèi)罩居涗浟藞?zhí)行時間超過閾值的SQL語句。在壓測過程中開啟它能直接看到是哪些SQL在拖后腿。配置其實很簡單slow_query_log 1 slow_query_log_file /var/log/mysql/slow.log long_query_time 1long_query_time設(shè)成1秒意思就是記錄所有執(zhí)行時間超過1秒的SQL。壓測跑完后用mysqldumpslow工具分析慢查詢?nèi)罩景磮?zhí)行次數(shù)和總耗時排序就能找到最值得優(yōu)化的幾條SQL。很多時候瓶頸就是兩三條慢SQL把它們優(yōu)化好了系統(tǒng)性能能肉眼可見地提高一個臺階。有一個細(xì)節(jié)要注意壓測環(huán)境里要把慢查詢?nèi)罩镜拈撝嫡{(diào)低一些比如0.5秒甚至0.2秒別只盯著1秒以上的。因為壓測環(huán)境的負(fù)載可能低于生產(chǎn)一條在生產(chǎn)環(huán)境要1秒的SQL在壓測環(huán)境只花0.8秒如果閾值設(shè)成1秒它就淹沒在日志里了。5.2 EXPLAIN告訴你索引到底有沒有生效優(yōu)化SQL時EXPLAIN是一個繞不開的工具。在慢SQL前加上EXPLAIN關(guān)鍵字MySQL會返回執(zhí)行計劃不需要真正執(zhí)行SQL。重點看type列和key列、rows列。type列從好到差大致是system、const、eq_ref、ref、range、index、ALL。出現(xiàn)ALL就意味著全表掃描這是最需要警惕的信號。key列顯示實際用到的索引如果為NULL說明這條SQL沒有走到索引。rows列是預(yù)估掃描的行數(shù)值越大說明成本越高。索引失效的情況有很多我遇到最多的三種隱式類型轉(zhuǎn)換、在索引列上使用函數(shù)、LIKE前導(dǎo)通配符。隱式類型轉(zhuǎn)換最常見比如WHERE user_id 123user_id列是數(shù)字類型卻拿字符串比較MySQL會做類型轉(zhuǎn)換索引就可能失效。在索引列上使用函數(shù)比如WHERE DATE(create_time) 2026-01-11對create_time做了日期函數(shù)處理索引當(dāng)然用不上正確寫法是WHERE create_time 2026-01-11 00:00:00 AND create_time 2026-01-12 00:00:00。LIKE前導(dǎo)通配符比如WHERE name LIKE %張三%也是索引失效的常見原因。5.3 改參數(shù)之前先記住連接池、緩沖池與并發(fā)參數(shù)要按順序動SQL層的問題解決后如果性能還不夠才考慮調(diào)整MySQL參數(shù)。常見的調(diào)整項包括max_connections、innodb_buffer_pool_size、innodb_flush_log_at_trx_commit。max_connections是最大連接數(shù)網(wǎng)上很多文章讓人“調(diào)得越大越好”這是誤解。每個連接都會占用內(nèi)存和線程資源連接數(shù)過大反而會因線程切換和資源爭搶讓性能下降。合理做法是壓測中觀察當(dāng)前連接數(shù)峰值然后留出20%到30%的余地。innodb_buffer_pool_size是InnoDB緩沖池大小直接影響磁盤和內(nèi)存之間的數(shù)據(jù)緩存效率。在專用MySQL實例上常見做法是設(shè)置到物理內(nèi)存的60%左右但必須根據(jù)實際數(shù)據(jù)量和讀寫比調(diào)整。調(diào)整后要觀察頁命中率沒有明顯改善就不必繼續(xù)加大。innodb_flush_log_at_trx_commit這個參數(shù)有三個取值0表示每秒刷一次日志到磁盤性能最高但崩潰時可能丟最后一秒數(shù)據(jù)1表示每次事務(wù)提交都刷磁盤最安全但性能最差2表示每次都寫入系統(tǒng)緩存性能和安全居中。具體選哪個取決于業(yè)務(wù)對數(shù)據(jù)一致性的容忍度。這里必須強(qiáng)調(diào)一條經(jīng)驗一次只改一個參數(shù)。我曾經(jīng)遇到一個團(tuán)隊把連接池、緩沖池、刷盤策略同時改了壓測結(jié)果反而比之前差排查半天才發(fā)現(xiàn)是連接數(shù)配置過高導(dǎo)致線程爭搶加劇。多個參數(shù)同時變動出了問題根本沒法判斷是誰造成的。改一個參數(shù)壓測一次對比前后數(shù)據(jù)再決定下一步動哪個。這個工作方式可能顯得慢但它是性能調(diào)優(yōu)最可靠的做法。6. 壓測調(diào)優(yōu)不是一次性交付多輪迭代、長穩(wěn)測試與容量基線復(fù)盤6.1 多輪壓測的節(jié)奏設(shè)計功能壓測、容量壓測、穩(wěn)定性壓測交替進(jìn)行壓測和調(diào)優(yōu)是一個循環(huán)過程不是跑一輪就結(jié)束了。我習(xí)慣把整個周期安排成三段走第一輪功能壓測第二輪容量壓測第三輪穩(wěn)定性壓測。功能壓測的目的不是測性能而是驗證腳本和系統(tǒng)在壓力下有沒有功能性錯誤。這一輪并發(fā)不要太高能暴露明顯的斷言失敗、接口報錯就行。容量壓測是核心按前面說的思路逐輪加壓找到系統(tǒng)的容量邊界。穩(wěn)定性壓測放在最后用容量壓測發(fā)現(xiàn)的80%左右的負(fù)載值讓系統(tǒng)持續(xù)跑8到24小時重點看內(nèi)存會不會緩慢增長、連接數(shù)會不會堆積、日志會不會越寫越多。實踐中的安排一般是白天團(tuán)隊都在的時候跑功能壓測和容量壓測有問題能馬上定位晚上掛上穩(wěn)定性壓測的腳本第二天早上看報告。長穩(wěn)測試最怕的是跑到夜里某個時間點掛了人卻不知道第二天大早看到空報告白白浪費一夜。所以長穩(wěn)測試期間要配置監(jiān)控告警至少做到失敗數(shù)突增或進(jìn)程崩潰時能通知到人。6.2 把每次結(jié)論沉淀成容量基線表壓測報告跑完就歸檔這是大部分團(tuán)隊的常態(tài)。但真正對后續(xù)迭代有幫助的是把報告里的關(guān)鍵數(shù)據(jù)整理成一張持續(xù)更新的容量基線表。表格格式可以參考這樣的結(jié)構(gòu)測試輪次日期環(huán)境工具版本并發(fā)線程數(shù)平均TPSP99響應(yīng)時間錯誤率CPU峰值內(nèi)存峰值結(jié)論12026-01-05壓測環(huán)境JMeter 5.6100800280ms0.05%40%60%正常22026-01-06壓測環(huán)境JMeter 5.62001200450ms0.10%65%75%P99偏高32026-01-07壓測環(huán)境JMeter 5.63001250800ms1.20%92%82%接近瓶頸這張表的價值在于每次發(fā)布新版本前跑一輪同樣的壓測把新數(shù)據(jù)和歷史基線對比就能快速判斷代碼改動有沒有引入性能回退。沒有基線光看當(dāng)次報告你很難知道“這個TPS到底是變好了還是變差了”。6.3 上線前的最后一輪復(fù)查全鏈路壓測多輪迭代和調(diào)優(yōu)后上線前的最后一輪復(fù)查也很重要。這輪不建議只看單節(jié)點盡量做全鏈路壓測網(wǎng)關(guān)、應(yīng)用、數(shù)據(jù)庫、Redis、消息隊列每個環(huán)節(jié)都要有監(jiān)控數(shù)據(jù)。這輪壓測有幾個重點檢查各環(huán)節(jié)的連接數(shù)和資源使用是否在合理范圍確認(rèn)限流和降級策略是否按預(yù)期觸發(fā)驗證壓測過程中產(chǎn)生的測試數(shù)據(jù)會不會殘留到生產(chǎn)庫。最后一點尤其容易被忽略壓測前記得設(shè)置好特殊的用戶標(biāo)識壓測后統(tǒng)一清理不然業(yè)務(wù)數(shù)據(jù)里混進(jìn)幾萬條測試訂單后面對賬會非常頭疼。壓測腳本放進(jìn)代碼庫管理、參數(shù)化測試數(shù)據(jù)定期刷新、報告按版本號歸檔這些細(xì)節(jié)看著瑣碎但它們是整條壓測流程能不能重復(fù)跑起來的關(guān)鍵。很多人做了一次壓測覺得沒效果往往就是輸在了這些不可復(fù)現(xiàn)的細(xì)節(jié)上。寫到這說點我自己的體會。壓測做多了以后我的習(xí)慣反而越來越“保守”拿到任何一份壓測報告先別急著改代碼先把“這次壓測到底問了什么問題”想清楚。問題定義對了工具和方法才有意義問題定義錯了TPS再高也是一份漂亮的廢紙。還有一個很實在的小技巧報告郵件里永遠(yuǎn)附帶壓測腳本的版本號和被測環(huán)境的指紋信息比如數(shù)據(jù)庫參數(shù)快照、壓測機(jī)配置、JMeter版本。不然三個月后回頭看報告你根本說不清當(dāng)時測的到底是什么基線表也就失去了價值。