據(jù)庫全指南：JDBC配置、參數(shù)化與并發(fā)實戰(zhàn))
1. 先想清楚壓數(shù)據(jù)庫和壓接口到底差在哪很多人用 JMeter 做接口測試、壓 Web 服務(wù)駕輕就熟。但一說到用 JMeter 直接壓數(shù)據(jù)庫不少人就懵了——數(shù)據(jù)庫也能用 JMeter 壓怎么連連上了能測啥先說結(jié)論不僅能壓而且非常好使。我在實際項目里既用 JMeter 壓過 MySQL、PostgreSQL也壓過 Oracle甚至給第三方數(shù)據(jù)中臺做過壓測靠的都是 JMeter 自帶的 JDBC 請求組件不需要裝任何額外插件。但有一個認(rèn)知必須先糾正用 JMeter 測數(shù)據(jù)庫不等于在數(shù)據(jù)庫客戶端里手動執(zhí)行幾條 SQL 看返回時間。它做的是“模擬真實業(yè)務(wù)場景下大量并發(fā)請求同時打向數(shù)據(jù)庫”這件事——比如 100 個用戶同時登錄每個登錄動作背后對應(yīng)著幾條 SQL這些 SQL 同時打到數(shù)據(jù)庫上數(shù)據(jù)庫扛不扛得住平均響應(yīng)時間多少有沒有慢查詢連接池會不會被打滿這才是壓數(shù)據(jù)庫的核心目的。所以這篇文章我不會只講“怎么連上數(shù)據(jù)庫”而是把 JMeter 測試數(shù)據(jù)庫的完整方法拆開揉碎環(huán)境準(zhǔn)備、JDBC 連接配置、JDBC Request 詳解、參數(shù)化傳值、斷言校驗、并發(fā)場景搭建、常見問題排查一條龍講清楚。你照著做基本可以覆蓋日常工作中 90% 的數(shù)據(jù)庫壓測需求。適合誰看剛接觸 JMeter、想用它做數(shù)據(jù)庫壓測的測試新人被領(lǐng)導(dǎo)臨時派活、需要在兩天內(nèi)給出數(shù)據(jù)庫性能結(jié)論的測試工程師以及那些已經(jīng)會基本接口壓測、但沒系統(tǒng)搞過 JDBC 請求的老手?？赐昴阒辽倌塥毩⒋畛鲆惶讕?shù)化、帶斷言、帶并發(fā)模型的數(shù)據(jù)庫壓測腳本。2. 環(huán)境準(zhǔn)備驅(qū)動、版本、連接方式一步都不能錯2.1 先確認(rèn) JMeter 版本和 JDBC 驅(qū)動開始之前先確認(rèn)你的 JMeter 版本。我這邊用的是 JMeter 5.xJDBC 請求相關(guān)的組件從 3.x 就有界面和配置項基本一致所以你用 4.x 或 5.x 都行不用太糾結(jié)版本。關(guān)鍵在于JDBC 驅(qū)動 Jar 包。JMeter 本身不自帶數(shù)據(jù)庫驅(qū)動你必須手動把對應(yīng)數(shù)據(jù)庫的驅(qū)動 Jar 包放到 JMeter 的lib目錄下然后重啟 JMeter 才能生效。常見數(shù)據(jù)庫對應(yīng)的驅(qū)動 Jar 包MySQLmysql-connector-java-8.0.x.jar如果你連的是 MySQL 5.x建議用 5.1.4x 版本MySQL 8.x 一定要用 8.0 版本的驅(qū)動不然連接會報錯。PostgreSQLpostgresql-42.x.x.jarOracleojdbc8.jar或ojdbc11.jar看你數(shù)據(jù)庫版本SQL Servermssql-jdbc-9.x.x.jar驅(qū)動包放好之后重啟 JMeter然后用一個最簡單的 JDBC 請求驗證一下能不能連上。別一上來就搞復(fù)雜場景連接都不通的話后面全是白搭。2.2 JDBC 驅(qū)動類名和連接 URL別記混了很多新手死在第一步就是驅(qū)動類名和 URL 寫錯。這里直接給你一份對照表抄作業(yè)就行數(shù)據(jù)庫JDBC Driver ClassJDBC URL 格式MySQLcom.mysql.jdbc.Driver5.x/com.mysql.cj.jdbc.Driver8.xjdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiPostgreSQLorg.postgresql.Driverjdbc:postgresql://127.0.0.1:5432/testdbOracleoracle.jdbc.OracleDriverjdbc:oracle:thin:127.0.0.1:1521/ORCLSQL Servercom.microsoft.sqlserver.jdbc.SQLServerDriverjdbc:sqlserver://127.0.0.1:1433;DatabaseNametestdb注意 MySQL 這里有兩個坑第一MySQL 5.x 和 8.x 的 Driver Class 不一樣。8.x 是com.mysql.cj.jdbc.Driver不是com.mysql.jdbc.Driver寫錯直接報ClassNotFoundException。第二MySQL 8.x 連接 URL 里建議加上useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/Shanghai。不加 serverTimezone 會報時區(qū)錯誤不加 allowPublicKeyRetrieval 會在某些認(rèn)證方式下報Public Key Retrieval is not allowed。這兩個參數(shù)我每次都會帶上省得排查半天。經(jīng)驗我一般會在連接 URL 里額外加一個connectTimeout5000socketTimeout10000避免數(shù)據(jù)庫掛了之后線程一直卡在等待上壓測時能很快暴露連接超時問題。比如jdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiconnectTimeout5000socketTimeout100002.3 環(huán)境驗證用一個最簡單的查詢打通鏈路驅(qū)動放好、配置想清楚了先做個連通性測試——在 JMeter 里建一個測試計劃加一個 JDBC Connection Configuration再選一個庫建一個線程池跑一條SELECT 1如果返回正常鏈路就通了。這一步別看簡單它價值很大能一次性排除驅(qū)動、URL、賬號密碼、網(wǎng)絡(luò)四個環(huán)節(jié)的問題。如果SELECT 1都跑不通那后面再復(fù)雜的腳本也跑不通不如先在這里把問題解決掉。3. JDBC Connection Configuration連接池配置才是壓測的關(guān)鍵3.1 配置項逐行拆解JDBC Connection Configuration 是 JDBC 請求的前置條件相當(dāng)于給所有 JDBC 請求提供數(shù)據(jù)庫連接池。它不是一個“填個 URL 就行”的簡單配置每個選項背后都有講究。關(guān)鍵的幾個配置項Variable Name for created pool連接池變量名隨便起比如db_pool但你要記死它因為 JDBC Request 里要通過這個名字來引用這個連接池。一個測試計劃里可以配置多個連接池給不同庫用靠名字區(qū)分。Max Number of Connections最大連接數(shù)。這個值很關(guān)鍵它決定了 JMeter 能同時從池里拿多少個連接。如果你壓 100 個并發(fā)但最大連接數(shù)只有 10那 JMeter 的請求就會排隊等連接測出來的結(jié)果不是數(shù)據(jù)庫的真實瓶頸而是連接池的瓶頸。Max Wait最大等待時間單位毫秒。連接池沒空閑連接時請求最多等多久超時拋異常。一般設(shè) 10000。Time Between Eviction Runs清理線程運行間隔。JMeter 會定期清理空閑過久的連接一般設(shè) 60000。Auto Commit自動提交。只做查詢壓測時設(shè) True 就好涉及事務(wù)、插入、更新時按需改成 False。Transaction Isolation事務(wù)隔離級別默認(rèn) DEFAULT 即可不用特別改。Pool Validation Query連接有效性檢查 SQL。MySQL 下寫SELECT 1PostgreSQL 下寫SELECT 1Oracle 下寫SELECT 1 FROM DUAL。JMeter 每次從池里拿連接時可以用這個 SQL 驗證連接是否還活著避免拿到失效連接。3.2 連接池參數(shù)怎么定一個簡單的估算方法連接池最大連接數(shù)怎么定很多教程會說“設(shè)大一點就行”但實際不是這么回事。連接數(shù)設(shè)太大數(shù)據(jù)庫可能會因為并發(fā)連接過多直接拒絕服務(wù)設(shè)太小JMeter 這邊又會排隊。我的做法是連接池最大連接數(shù) 目標(biāo)并發(fā)線程數(shù)。比如你要模擬 100 個用戶并發(fā)那么 Max Number of Connections 就設(shè) 100 或略大于 100比如 100。這樣每個線程拿到一個獨立連接不會出現(xiàn)兩個線程搶一個連接的情況。這里有個容易混淆的細節(jié)JMeter 的線程數(shù)和連接池連接數(shù)不是一一綁定的關(guān)系。線程可以復(fù)用連接但如果你想測的是“數(shù)據(jù)庫在 100 個并發(fā)連接下的表現(xiàn)”那連接數(shù)就必須給夠否則測出來的曲線是連接池排隊曲線不是數(shù)據(jù)庫性能曲線。3.3 為什么要用連接池而不是每個線程單獨連JMeter 里還有一種做法是每個線程自己創(chuàng)建數(shù)據(jù)庫連接不用連接池——比如用 BeanShell 或者 JSR223 寫代碼去DriverManager.getConnection()。我不推薦這種方式做壓測原因有兩個第一性能差。每次請求都重新創(chuàng)建連接開銷全花在 TCP 握手和認(rèn)證上測出來的響應(yīng)時間虛高。第二資源不可控。并發(fā) 100 個線程同時創(chuàng)建 100 個連接壓測機本身的文件描述符、內(nèi)存壓力都會變大干擾結(jié)果。所以標(biāo)準(zhǔn)做法就是一個 JDBC Connection Configuration 管連接池N 個 JDBC Request 從池里取連接執(zhí)行 SQL。連接池的創(chuàng)建、復(fù)用、回收J(rèn)Meter 都在底層幫你處理好了你要做的就是配置好那幾項參數(shù)。4. JDBC Request 詳解增刪改查都能壓4.1 SQL 查詢和變量名規(guī)則JDBC Request 是真正執(zhí)行 SQL 的地方。它長得很像一個 HTTP 請求 Sample但參數(shù)完全不同。核心參數(shù)有三個Variable Name of Pool declared in JDBC Connection Configuration填連接池變量名也就是你在 JDBC Connection Configuration 里填的那個名字。如果這里填錯JMeter 會直接報錯找不到連接池。Query TypeSQL 類型有 Select Statement、Update Statement、Callable Statement、Prepared Select Statement、Prepared Update Statement 等。如果是普通查詢用 Select Statement如果 SQL 里有占位符?必須用 Prepared Select Statement 或 Prepared Update Statement。QuerySQL 語句本體。這里有個新手高頻疑問Query Type 選 Select Statement 和 Prepared Select Statement 有什么區(qū)別區(qū)別在占位符。如果你要執(zhí)行SELECT * FROM user WHERE id ?就必須用 Prepared Select Statement然后通過參數(shù)列表傳入?的值。如果你執(zhí)行的是完整 SQL沒有?用 Select Statement 就行。相同點是結(jié)果都存放在變量里供后續(xù)使用。4.2 查詢結(jié)果的三種用法JDBC Request 執(zhí)行完之后結(jié)果存在哪答案是JMeter 會把結(jié)果集存到變量里變量名規(guī)則是你在 JDBC Request 里填的Variable Name。比如你在 JDBC Request 的 Variable Name 填了mysql_result那么執(zhí)行完查詢后mysql_result整個結(jié)果集mysql_result_#結(jié)果集行數(shù)比如返回 10 行這個變量值就是 10mysql_result_1第一行數(shù)據(jù)mysql_result_1_id第一行的 id 字段值mysql_result_2_id第二行的 id 字段值用Variable Name 下劃線 行號 下劃線 列名這個規(guī)則就能取到任意一行任意一列的值。這個特性相當(dāng)有用。最常見的場景是你從表 A 查到一批訂單 ID然后要把這些 ID 作為參數(shù)傳給下一個 JDBC Request 或 HTTP 請求。具體做法就是先執(zhí)行一條查詢 SQL然后在下一個請求里用${mysql_result_1_id}來引用第一行 ID。4.3 實際案例查詢用戶表數(shù)據(jù)我來演示一個最簡單的例子。假設(shè)數(shù)據(jù)庫里有一張user表字段有id、username、age我想壓測一條查詢 SQLSELECT id, username, age FROM user WHERE age 20配置如下JDBC Request Variable Nameuser_resultQuery TypeSelect StatementQuerySELECT id, username, age FROM user WHERE age 20跑完之后在察看結(jié)果樹里可以看到這個 JDBC Request 的響應(yīng)數(shù)據(jù)里面是查到的所有行。如果你想把這批數(shù)據(jù)取出來給后續(xù)請求用比如遍歷前 10 個用戶 ID就可以用${user_result_1_id}、${user_result_2_id}這種形式去引用。注意結(jié)果集會按位置存儲mysql_result_1是第 1 行mysql_result_2是第 2 行以此類推。如果你查詢結(jié)果本身有排序需求在 SQL 里把ORDER BY寫好否則取出來的行順序可能不穩(wěn)定。4.4 執(zhí)行更新操作怎么配置壓測不光是查詢有時也要模擬寫入、更新的業(yè)務(wù)壓力。比如 100 個用戶同時更新自己的資料。如果是帶參數(shù)的更新比如UPDATE user SET age ? WHERE id ?那么 Query Type 要選Prepared Update StatementSQL 里的?是占位符需要通過“Parameter values”和“Parameter types”傳入實際值。這里有個重要細節(jié)執(zhí)行 Update/Insert/Delete 操作時如果數(shù)據(jù)庫沒有返回結(jié)果集JMeter 會返回受影響的行數(shù)。比如某個 UPDATE 影響了 3 行JMeter 的響應(yīng)數(shù)據(jù)里會顯示3。如果你想驗證更新是否成功一種做法是更新后再執(zhí)行一條 SELECT 去查這條數(shù)據(jù)配合斷言來校驗。5. 參數(shù)化取值讓壓測數(shù)據(jù)動起來5.1 CSVDataset 參數(shù)化每個線程分塊取值做數(shù)據(jù)庫壓測時你常常需要模擬“不同的用戶操作不同的數(shù)據(jù)”而不是 100 個用戶都查同一條記錄。前者才是真實業(yè)務(wù)場景也能更有效地壓出數(shù)據(jù)庫的查詢能力。JMeter 里最常用的參數(shù)化方式就是CSV 數(shù)據(jù)集配置CSV Data Set Config。它允許你從一個 CSV 文件里按行讀取數(shù)據(jù)然后把每一列的值賦給變量。配置的時候有幾點要注意FilenameCSV 文件路徑Variable Names列名用英文逗號分隔比如id,username,ageDelimiter分隔符默認(rèn)是英文逗號Recycle on EOF讀完最后一行后是否回到開頭繼續(xù)讀。如果你壓測時長較長或者并發(fā)數(shù)大于 CSV 行數(shù)建議設(shè) True否則讀到末尾線程會直接結(jié)束或報錯。Stop thread on EOF讀完最后一行是否停止線程。如果 Recycle on EOF 是 True這個就設(shè) False。Sharing mode共享模式。默認(rèn) All threads 是所有線程共享一個文件指針按順序往下讀如果你想每個線程各讀各的可以選 Current thread。我在實際項目里壓“100 并發(fā)用戶登錄”時會準(zhǔn)備一個 100 行的 CSV每行一個用戶 ID 和密碼然后把線程組并發(fā)數(shù)設(shè)為 100CSV 共享模式用默認(rèn)的 All threads這樣每個線程拿到一個不同的用戶數(shù)據(jù)誰也不會搶。5.2 從上一個查詢結(jié)果取參JDBC 請求結(jié)果復(fù)用CSV 適合數(shù)據(jù)預(yù)先準(zhǔn)備好的場景但有些場景數(shù)據(jù)是動態(tài)生成的——你先要查一下有哪些訂單然后針對每個訂單做后續(xù)操作。這種時候就要用 JDBC Request 的查詢結(jié)果來做參數(shù)化。思路是先跑一條 SELECT把結(jié)果存到一個變量里然后在后一個請求里用${var_行號_列名}去引用。舉個例子第一步JDBC Request 查訂單 IDSELECT order_id, amount FROM orders WHERE status pending這個 JDBC Request 的 Variable Name 設(shè)為order_result。第二步在 HTTP 請求或下一個 JDBC Request 里引用訂單 ID${order_result_1_order_id} 訂單金額${order_result_1_amount}這樣就實現(xiàn)了“把數(shù)據(jù)庫查出來的數(shù)據(jù)作為下一個接口的參數(shù)”這個高頻需求。但如果查詢返回了多行而你希望循環(huán)處理每一行數(shù)據(jù)那還是建議配合ForEach 控制器來做。ForEach 控制器可以遍歷一個變量集合比如order_result下的所有行然后逐一執(zhí)行后續(xù)請求。配置時輸入變量前綴order_result循環(huán)變量名隨便取一個比如current_order然后在后續(xù)請求里用${current_order_order_id}就能依次取到每一行的數(shù)據(jù)。5.3 JDBC 請求結(jié)果里的特殊變量行數(shù)和 NULL使用查詢結(jié)果時有兩個場景很容易踩坑。第一空結(jié)果集。如果 SQL 查不到數(shù)據(jù)order_result_#會是 0此時不能引用order_result_1_order_id否則 JMeter 會輸出一個空值。為了不報錯可以搭配If 控制器判斷order_result_#是否大于 0再執(zhí)行后續(xù)邏輯。第二字段值本身是 NULL。比如某個字段在某些行里是 NULL引用之后得到的字符串是null而不是空字符串。如果你的下游接口對參數(shù)格式有嚴(yán)格要求需要在 BeanShell 或 JSR223 里做一個 null 值替換處理否則接口調(diào)用可能會因為多傳了null字符串而報錯。5.4 直接用 JSR223 腳本搞定更復(fù)雜的數(shù)據(jù)加工如果上面的方式都滿足不了需求比如你要對查出來的數(shù)據(jù)進行 MD5 加密后作為參數(shù)傳給接口那就得上 JSR223 腳本了。JSR223 Sampler 里可以用 Groovy 直接查數(shù)據(jù)庫處理結(jié)果集生成任意格式的字符串。Groovy 的語法比 BeanShell 簡潔太多性能也更好是 JMeter 官方推薦的方式。雖然這篇文章主要講 JDBC Request 這種圖形化配置但在自定義邏輯非常復(fù)雜的時候JSR223 是終極兜底方案。簡單示例import java.sql.* // 獲取連接池里的連接 def conn vars.get(db_pool) // 這只是示意 // 真實的連接獲取可以通過 DataSource 或者直接用 JDBC 驅(qū)動獲取這里省略不過說實話只有你需要寫復(fù)雜邏輯時才用 JSR223一般情況下 JDBC Request CSV 已經(jīng)能覆蓋絕大多數(shù)場景。過度使用 JSR223 反而會讓腳本難以維護。6. 斷言校驗怎么證明數(shù)據(jù)庫返回是對的6.1 響應(yīng)斷言最快最直接的校驗方式壓數(shù)據(jù)庫不是把 SQL 跑完就完事了你得確認(rèn)返回內(nèi)容是符合預(yù)期的。比如你查詢age 20的用戶結(jié)果返回里至少有數(shù)據(jù)行而不是空結(jié)果集或者一堆錯誤信息。JMeter 的響應(yīng)斷言可以加到 JDBC Request 上用來校驗響應(yīng)內(nèi)容。配置方式很簡單在 JDBC Request 上右鍵 → Add → Assertions → Response AssertionField to Test選 Text ResponsePattern Matching Rules選 ContainsPatterns to Test填你要校驗的關(guān)鍵字比如查詢user表你想確認(rèn)結(jié)果里有username這個字段名就可以在響應(yīng)斷言里填username。如果響應(yīng)里沒有這個關(guān)鍵字?jǐn)嘌跃蜁≡诰酆蠄蟾胬飼吹藉e誤率上升。這里有個技巧有時候 SQL 查出來的數(shù)據(jù)量很大響應(yīng)內(nèi)容很長你沒法直觀地看到是否有數(shù)據(jù)這時可以直接用響應(yīng)斷言校驗 “返回行數(shù)不為 0”。具體做法是把 SQL 改成SELECT COUNT(*) AS cnt FROM user WHERE age 20然后斷言響應(yīng)里包含cnt10或某個具體數(shù)字。注意JMeter 響應(yīng)里 COUNT 查詢的顯示格式是類似cnt10這樣的配合 Contains 斷言就能判斷數(shù)據(jù)量是否符合預(yù)期。6.2 BeanShell 斷言處理復(fù)雜校驗邏輯響應(yīng)斷言只能做簡單匹配如果你要做復(fù)雜判斷比如“查詢結(jié)果里最大金額大于 1000”或“返回行數(shù)在某個區(qū)間內(nèi)”就得用 BeanShell 斷言或者 JSR223 斷言。JSR223 斷言可以用 Groovy 寫邏輯清晰多了。比如判斷結(jié)果集行數(shù)def rowCount vars.get(user_result_#).toInteger() if (rowCount 10) { // 失敗手動設(shè)置斷言結(jié)果 AssertionResult.setFailure(true) AssertionResult.setFailureMessage(查詢結(jié)果集行數(shù)小于10實際為: rowCount) }這段腳本的邏輯是從 JMeter 變量里取user_result_#的值轉(zhuǎn)成整數(shù)判斷是否小于 10如果小于就手動標(biāo)記斷言失敗并輸出失敗原因。這樣在聚合報告或察看結(jié)果樹里你能很直觀地看到哪些請求沒通過校驗。經(jīng)驗斷言別加太多加的每一個斷言都會消耗額外的性能。壓測腳本里的斷言越精簡越好能用一個響應(yīng)斷言解決的就不要加腳本斷言。高并發(fā)壓測時過重的斷言會拉高 JMeter 本身的 CPU 開銷影響測試數(shù)據(jù)準(zhǔn)確性。6.3 結(jié)合“用結(jié)果樹看數(shù)據(jù)”排查問題壓測跑完后第一件事永遠是看察看結(jié)果樹View Results Tree。在結(jié)果樹里每個 JDBC Request 都能展開看它的請求數(shù)據(jù)、響應(yīng)數(shù)據(jù)、斷言結(jié)果。響應(yīng)數(shù)據(jù)里會顯示 SQL 執(zhí)行后返回的內(nèi)容格式。我遇到過很多測試小白寫完了腳本直接開壓壓完發(fā)現(xiàn)錯誤率 100%然后開始懷疑數(shù)據(jù)庫出問題了。其實根本不是數(shù)據(jù)庫的問題而是 SQL 寫錯了或者參數(shù)沒傳進去。這種時候不用慌打開察看結(jié)果樹找一個失敗的請求看它的響應(yīng)數(shù)據(jù)里的報錯信息十有八九一次就能定位到問題。7. 并發(fā)壓測實戰(zhàn)模擬 100 個用戶同時查庫7.1 線程組參數(shù)設(shè)計前面把 JDBC Request 和參數(shù)化都講完了接下來進入實戰(zhàn)模式——模擬 100 個用戶同時訪問數(shù)據(jù)庫看數(shù)據(jù)庫的表現(xiàn)。線程組配置建議Number of Threads (users)100Ramp-Up Period (seconds)10Loop Count50 或者填 ∞根據(jù)你的壓測時長來定這里解釋一下 Ramp-Up Period 的作用它表示 100 個線程在 10 秒內(nèi)全部啟動完畢也就是說每秒啟動 10 個線程。這樣做是為了模擬用戶逐步進入系統(tǒng)的真實場景而不是 100 個請求在同一毫秒內(nèi)全部打到數(shù)據(jù)庫。如果你希望一開始就是滿負(fù)載可以把 Ramp-Up 設(shè)成 1 秒如果你要做階梯壓測可以用 Stepping Thread Group 插件但這個插件需要額外安裝基礎(chǔ)場景下普通線程組就夠用了。Loop Count 表示每個線程執(zhí)行多少次查詢。假如一個 JDBC Request 執(zhí)行一條 SQL100 個線程 × 循環(huán) 50 次 總共 5000 次 SQL 查詢。這個總數(shù)可以用來估算壓測時長和數(shù)據(jù)庫負(fù)載。7.2 實戰(zhàn)腳本結(jié)構(gòu)一個標(biāo)準(zhǔn)的數(shù)據(jù)庫壓測腳本結(jié)構(gòu)如下測試計劃線程組100 線程10 秒內(nèi)啟動JDBC Connection Configuration連接池配置最大連接數(shù) 100CSV Data Set Config用戶數(shù)據(jù)參數(shù)化JDBC Request執(zhí)行 SQL響應(yīng)斷言校驗返回結(jié)果監(jiān)聽器聚合報告Aggregate Report察看結(jié)果樹View Results Tree需要注意JDBC Connection Configuration 和 CSV Data Set Config 都是配置元件Config Element它們的作用范圍是“所在層級之下的所有請求”。放在線程組下就對該線程組里的所有 JDBC Request 生效。7.3 壓測過程中的實時監(jiān)控壓測跑起來之后除了看 JMeter 的聚合報告我強烈建議你同時監(jiān)控數(shù)據(jù)庫端的指標(biāo)。光看 JMeter 的響應(yīng)時間是不夠的你還需要知道數(shù)據(jù)庫的 CPU、內(nèi)存、連接數(shù)、慢查詢數(shù)等指標(biāo)才能完整評估數(shù)據(jù)庫性能。具體做法如果是 MySQL可以在壓測時執(zhí)行SHOW PROCESSLIST;查看當(dāng)前所有連接和正在執(zhí)行的 SQL。查看數(shù)據(jù)庫的 CPU 和內(nèi)存占用比如用top或數(shù)據(jù)庫自帶的性能監(jiān)控工具。開啟慢查詢?nèi)罩緣簻y完后分析哪些 SQL 的執(zhí)行時間超過了閾值。這一步非常重要因為 JMeter 的聚合報告只能告訴你“響應(yīng)時間變慢了”但到底慢在數(shù)據(jù)庫的哪個環(huán)節(jié)——是 CPU 打滿了、還是鎖等待、還是磁盤 IO——必須結(jié)合數(shù)據(jù)庫端的指標(biāo)來看。7.4 聚合報告怎么解讀壓測結(jié)束看聚合報告的幾個核心指標(biāo)Samples總請求數(shù)Average平均響應(yīng)時間單位毫秒Min / Max最小/最大響應(yīng)時間Std. Dev.響應(yīng)時間標(biāo)準(zhǔn)差越大說明響應(yīng)時間波動越明顯性能越不穩(wěn)定Error %錯誤率正常壓測場景下應(yīng)為 0%有少量錯誤要具體分析Throughput吞吐量單位通常是req/sec意思是每秒能處理多少請求舉個例子100 個線程、循環(huán) 50 次的腳本跑完Samples 是 5000Throughput 如果是 200/sec說明數(shù)據(jù)庫每秒能扛住 200 次這個 SQL 查詢。如果你把循環(huán)次數(shù)加大Throughput 會逐步逼近數(shù)據(jù)庫的極限值這個極限值就是數(shù)據(jù)庫的處理能力上限。經(jīng)驗壓測數(shù)據(jù)庫時平均響應(yīng)時間和吞吐量要一起看。如果平均響應(yīng)時間很低但吞吐量也低說明 JMeter 本身或網(wǎng)絡(luò)成了瓶頸不是數(shù)據(jù)庫不行如果吞吐量上去了但平均響應(yīng)時間也跟著飆升這才說明數(shù)據(jù)庫開始進入高負(fù)載狀態(tài)。8. 常見問題與排查技巧實錄8.1 連接不通ClassNotFoundException 和 URL 報錯問題現(xiàn)象JDBC Request 報ClassNotFoundException: com.mysql.jdbc.Driver或Cannot create PoolableConnectionFactory。排查思路先看驅(qū)動 Jar 包有沒有放到 JMeter 的 lib 目錄下然后看是否重啟了 JMeter。如果確定 Jar 包在再看 Driver Class 寫對沒有——MySQL 8.x 驅(qū)動對應(yīng)的是com.mysql.cj.jdbc.Driver不是com.mysql.jdbc.Driver。如果報錯信息是Unknown database xxx檢查連接 URL 里的數(shù)據(jù)庫名是否正確。如果是Access denied for user檢查賬號密碼和數(shù)據(jù)庫權(quán)限。8.2 連接池不夠用Too many connections問題現(xiàn)象壓測過程中JMeter 報Too many connections或者數(shù)據(jù)庫端出現(xiàn)Connection refused。原因分析這個報錯有兩個方向一個是 JMeter 連接池最大連接數(shù)設(shè)得太大打爆了數(shù)據(jù)庫的最大連接數(shù)另一個是數(shù)據(jù)庫自身max_connections配置太小。解決方案先查看數(shù)據(jù)庫的max_connections比如 MySQL 可以用SHOW VARIABLES LIKE max_connections;查看。然后調(diào)整 JMeter 連接池的最大連接數(shù)讓它的上限略低于數(shù)據(jù)庫的max_connections留一些余量給其他應(yīng)用連接。順便說一句做壓測之前一定要和 DBA 或運維確認(rèn)好數(shù)據(jù)庫的連接上限否則壓到一半數(shù)據(jù)庫直接把連接全踢掉測試結(jié)果就廢了。8.3 響應(yīng)時間異常長慢 SQL 還是連接池排隊問題現(xiàn)象聚合報告顯示平均響應(yīng)時間高達幾秒遠大于你手動執(zhí)行 SQL 的時間。原因分析首先要區(qū)分是數(shù)據(jù)庫真慢還是連接池在排隊。手動執(zhí)行 SQL 快說明 SQL 本身沒問題。這時候要去看 JMeter 連接池的最大連接數(shù)是不是小于線程數(shù)——如果 100 個線程去搶 20 個連接剩下 80 個線程全在等連接響應(yīng)時間自然飆升。解決方案把 Max Number of Connections 調(diào)大使其等于或大于線程數(shù)再跑一次對比。如果響應(yīng)時間正常了說明之前的瓶頸是連接池如果響應(yīng)時間依然很大那就要去數(shù)據(jù)庫端看慢查詢?nèi)罩径ㄎ皇遣皇撬饕А㈡i等待等問題。還有一個細節(jié)如果連接 URL 設(shè)置了socketTimeout當(dāng)數(shù)據(jù)庫處理查詢超過這個值時JMeter 會直接報 socket 超時。這種情況下不是數(shù)據(jù)庫變慢而是策略性地斷開了連接。壓測時可以把 socketTimeout 調(diào)大一點避免誤判。8.4 變量引用出來是 null結(jié)果集行號與字段大小寫問題現(xiàn)象在后續(xù)請求里用${var_1_id}引用 JDBC 查詢結(jié)果發(fā)現(xiàn)值是 null 或者空字符串。原因排查第一先看結(jié)果集是不是空的。如果 SQL 查不出來數(shù)據(jù)任何引用都是空。用察看結(jié)果樹看響應(yīng)數(shù)據(jù)確認(rèn)是否有數(shù)據(jù)返回。第二看字段名大小寫。MySQL 的字段名默認(rèn)全小寫如果 SQL 里寫了別名比如SELECT id AS userId FROM user那么引用時要寫成${var_1_userId}。建議 SQL 里起別名時統(tǒng)一用帶下劃線的命名如user_id然后引用時保持大小寫一致。第三行號從 1 開始不是從 0 開始。如果變量名是order_result那么第一行是order_result_1沒有order_result_0這個變量。8.5 中文亂碼與編碼問題問題現(xiàn)象JDBC 查詢返回的中文變成問號或亂碼。原因排查大多是連接 URL 里沒有指定字符集。在 MySQL 連接 URL 上加上characterEncodingutf8jdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaicharacterEncodingutf8另外檢查數(shù)據(jù)庫表本身的字符集是不是 utf8mb4。如果表是 latin1 而應(yīng)用按 utf8 讀取也會亂碼。8.6 一個容易被忽略的問題壓測機性能不夠最后提一個很多人踩過的坑——壓測機本身的性能不夠。JMeter 是 Java 應(yīng)用100 個并發(fā)線程跑起來時壓測機 CPU 和內(nèi)存消耗不小。如果你在本地筆記本上壓遠程數(shù)據(jù)庫壓測結(jié)果可能不是你 SQL 的真實性能而是筆記本 CPU 打滿后的結(jié)果。怎么判斷壓測時打開任務(wù)管理器或top看看 Java 進程的 CPU 占用率。如果已經(jīng)超過了機器 CPU 的 70% 以上建議換一臺性能更強的機器或者把 JMeter 部署到另一臺服務(wù)器上盡量讓壓測機資源充足確保瓶頸在數(shù)據(jù)庫端而不是客戶端。8.7 問題排查速查表問題現(xiàn)象可能原因解決方案ClassNotFoundException驅(qū)動 Jar 未放到 lib 目錄放入 Jar 包并重啟 JMeterCannot create PoolableConnectionFactoryURL 或賬號密碼錯誤檢查 URL 格式、賬號權(quán)限Too many connections連接數(shù)超過數(shù)據(jù)庫上限調(diào)大數(shù)據(jù)庫 max_connections 或調(diào)小 JMeter 連接池響應(yīng)時間超長連接池排隊或慢 SQL調(diào)大連接池查看慢查詢?nèi)罩咀兞恐禐?null結(jié)果集為空或字段名大小寫不一致確認(rèn)查詢結(jié)果檢查 SQL 別名中文亂碼連接 URL 未指定字符集添加 characterEncodingutf8壓測結(jié)果不穩(wěn)定壓測機資源不足更換壓測機或降低線程數(shù)9. 一個完整的數(shù)據(jù)庫壓測腳本示例講了這么多最后給你一個完整的 MySQL 壓測腳本搭建過程從零到一可以直接照抄。9.1 測試場景模擬 100 個用戶并發(fā)查詢訂單表每個查詢根據(jù)不同的訂單 ID 查詢訂單信息持續(xù)壓測 10 分鐘觀察數(shù)據(jù)庫的吞吐量和響應(yīng)時間變化。9.2 準(zhǔn)備工作MySQL 數(shù)據(jù)庫提前創(chuàng)建好訂單表orders字段包括order_id、user_id、amount、status準(zhǔn)備一個order_ids.csv文件里面放 100 個訂單 ID用于參數(shù)化JMeter 5.xmysql-connector-java-8.0.x.jar已放入 lib 目錄并重啟9.3 腳本搭建步驟第一步創(chuàng)建測試計劃并添加線程組線程數(shù) 100Ramp-Up 10 秒循環(huán)次數(shù)勾選無限在調(diào)度器配置里設(shè)置持續(xù)時間為 600 秒。第二步添加 JDBC Connection Configuration配置項如下Variable Name for created poolmysql_poolMax Number of Connections100Max Wait10000Auto CommitTruePool Validation QuerySELECT 1Database Connection ConfigurationDatabase URLjdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiJDBC Driver Classcom.mysql.cj.jdbc.DriverUsernametest_userPasswordyour_password第三步添加 CSV Data Set ConfigFilename/data/order_ids.csvVariable Namesorder_idDelimiter,Recycle on EOFTrueStop thread on EOFFalseSharing modeAll threads第四步添加 JDBC RequestVariable Name of Poolmysql_poolQuery TypePrepared Select StatementQuerySELECT * FROM orders WHERE order_id ?Parameter values${order_id}Parameter typesVARCHAR這里說明一下因為 SQL 里有?占位符所以 Query Type 必須選 Prepared Select StatementParameter values 里填 CSV 讀取出來的訂單 IDParameter types 填數(shù)據(jù)庫字段類型。第五步添加響應(yīng)斷言Field to TestText ResponsePattern Matching RulesContainsPatterns to Testorder_id這樣就確保了查詢請求返回的結(jié)果中包含 order_id 字段證明查詢是成功的。第六步添加監(jiān)聽器加一個聚合報告和一個察看結(jié)果樹。壓測結(jié)束后聚合報告里可以看到平均響應(yīng)時間、吞吐量、錯誤率等核心數(shù)據(jù)。9.4 跑完怎么分析壓測結(jié)束后我一般這么看數(shù)據(jù)先看錯誤率。如果錯誤率為 0%說明 100 并發(fā)下這條 SQL 沒有出錯數(shù)據(jù)庫連接和查詢都正常。如果錯誤率大于 0查詢具體的錯誤信息常見的是連接池不夠用或超時。然后看吞吐量變化。如果 JMeter 的 Throughput 在持續(xù)穩(wěn)定上升后趨于平緩說明已經(jīng)摸到了數(shù)據(jù)庫的處理上限。此時如果平均響應(yīng)時間還能接受說明數(shù)據(jù)庫還有冗余如果響應(yīng)時間已經(jīng)超標(biāo)比如超過 500ms說明數(shù)據(jù)庫快要撐不住了。最后結(jié)合數(shù)據(jù)庫端監(jiān)控比如 CPU、慢查詢?nèi)罩究雌款i到底在哪個環(huán)節(jié)然后給出測試結(jié)論和優(yōu)化建議。這里有一個小建議壓測時先把線程數(shù)保守一點比如 50跑一輪看結(jié)果再逐步升到 100、200。這樣做的好處是你能看到數(shù)據(jù)庫在不同并發(fā)下的表現(xiàn)曲線而不是一上來就壓到天花板拿到一堆根本沒法分析的數(shù)據(jù)。階梯式加壓是我在實際項目中比較喜歡用的方式。最后說幾句實在話用 JMeter 做數(shù)據(jù)庫壓測門檻真的不高但想做好需要你對數(shù)據(jù)庫本身的運行機制有基本認(rèn)知。我在實際測試項目里見過不少人把壓測腳本配好了、跑出了漂亮的報告但一問數(shù)據(jù)庫端的指標(biāo)完全答不上來——CPU 多少、內(nèi)存多少、慢查詢有沒有、連接數(shù)有沒有到上限全是空白。這種壓測報告說實話價值有限。我的個人建議是壓測數(shù)據(jù)庫永遠要把 JMeter 端的數(shù)據(jù)和數(shù)據(jù)庫端的數(shù)據(jù)結(jié)合起來看。JMeter 告訴你發(fā)生了什么數(shù)據(jù)庫的監(jiān)控告訴你為什么會發(fā)生。兩邊對照才能真正判斷數(shù)據(jù)庫的性能瓶頸在哪里也才能給出可信的測試結(jié)論。如果你只是剛接觸這塊先從最簡單的單條 SQL 查詢壓測入手把 JDBC Connection Configuration 和 JDBC Request 玩熟再慢慢加參數(shù)化、加斷言、加并發(fā)場景。不要一上來就想測多表關(guān)聯(lián)或存儲過程底子打好后面的內(nèi)容都是水到渠成的事。 JMeter壓測數(shù)據(jù)庫全指南：JDBC配置、參數(shù)化與并發(fā)實戰(zhàn)
1. 先想清楚壓數(shù)據(jù)庫和壓接口到底差在哪很多人用 JMeter 做接口測試、壓 Web 服務(wù)駕輕就熟。但一說到用 JMeter 直接壓數(shù)據(jù)庫不少人就懵了——數(shù)據(jù)庫也能用 JMeter 壓怎么連連上了能測啥先說結(jié)論不僅能壓而且非常好使。我在實際項目里既用 JMeter 壓過 MySQL、PostgreSQL也壓過 Oracle甚至給第三方數(shù)據(jù)中臺做過壓測靠的都是 JMeter 自帶的 JDBC 請求組件不需要裝任何額外插件。但有一個認(rèn)知必須先糾正用 JMeter 測數(shù)據(jù)庫不等于在數(shù)據(jù)庫客戶端里手動執(zhí)行幾條 SQL 看返回時間。它做的是“模擬真實業(yè)務(wù)場景下大量并發(fā)請求同時打向數(shù)據(jù)庫”這件事——比如 100 個用戶同時登錄每個登錄動作背后對應(yīng)著幾條 SQL這些 SQL 同時打到數(shù)據(jù)庫上數(shù)據(jù)庫扛不扛得住平均響應(yīng)時間多少有沒有慢查詢連接池會不會被打滿這才是壓數(shù)據(jù)庫的核心目的。所以這篇文章我不會只講“怎么連上數(shù)據(jù)庫”而是把 JMeter 測試數(shù)據(jù)庫的完整方法拆開揉碎環(huán)境準(zhǔn)備、JDBC 連接配置、JDBC Request 詳解、參數(shù)化傳值、斷言校驗、并發(fā)場景搭建、常見問題排查一條龍講清楚。你照著做基本可以覆蓋日常工作中 90% 的數(shù)據(jù)庫壓測需求。適合誰看剛接觸 JMeter、想用它做數(shù)據(jù)庫壓測的測試新人被領(lǐng)導(dǎo)臨時派活、需要在兩天內(nèi)給出數(shù)據(jù)庫性能結(jié)論的測試工程師以及那些已經(jīng)會基本接口壓測、但沒系統(tǒng)搞過 JDBC 請求的老手?？赐昴阒辽倌塥毩⒋畛鲆惶讕?shù)化、帶斷言、帶并發(fā)模型的數(shù)據(jù)庫壓測腳本。2. 環(huán)境準(zhǔn)備驅(qū)動、版本、連接方式一步都不能錯2.1 先確認(rèn) JMeter 版本和 JDBC 驅(qū)動開始之前先確認(rèn)你的 JMeter 版本。我這邊用的是 JMeter 5.xJDBC 請求相關(guān)的組件從 3.x 就有界面和配置項基本一致所以你用 4.x 或 5.x 都行不用太糾結(jié)版本。關(guān)鍵在于JDBC 驅(qū)動 Jar 包。JMeter 本身不自帶數(shù)據(jù)庫驅(qū)動你必須手動把對應(yīng)數(shù)據(jù)庫的驅(qū)動 Jar 包放到 JMeter 的lib目錄下然后重啟 JMeter 才能生效。常見數(shù)據(jù)庫對應(yīng)的驅(qū)動 Jar 包MySQLmysql-connector-java-8.0.x.jar如果你連的是 MySQL 5.x建議用 5.1.4x 版本MySQL 8.x 一定要用 8.0 版本的驅(qū)動不然連接會報錯。PostgreSQLpostgresql-42.x.x.jarOracleojdbc8.jar或ojdbc11.jar看你數(shù)據(jù)庫版本SQL Servermssql-jdbc-9.x.x.jar驅(qū)動包放好之后重啟 JMeter然后用一個最簡單的 JDBC 請求驗證一下能不能連上。別一上來就搞復(fù)雜場景連接都不通的話后面全是白搭。2.2 JDBC 驅(qū)動類名和連接 URL別記混了很多新手死在第一步就是驅(qū)動類名和 URL 寫錯。這里直接給你一份對照表抄作業(yè)就行數(shù)據(jù)庫JDBC Driver ClassJDBC URL 格式MySQLcom.mysql.jdbc.Driver5.x/com.mysql.cj.jdbc.Driver8.xjdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiPostgreSQLorg.postgresql.Driverjdbc:postgresql://127.0.0.1:5432/testdbOracleoracle.jdbc.OracleDriverjdbc:oracle:thin:127.0.0.1:1521/ORCLSQL Servercom.microsoft.sqlserver.jdbc.SQLServerDriverjdbc:sqlserver://127.0.0.1:1433;DatabaseNametestdb注意 MySQL 這里有兩個坑第一MySQL 5.x 和 8.x 的 Driver Class 不一樣。8.x 是com.mysql.cj.jdbc.Driver不是com.mysql.jdbc.Driver寫錯直接報ClassNotFoundException。第二MySQL 8.x 連接 URL 里建議加上useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/Shanghai。不加 serverTimezone 會報時區(qū)錯誤不加 allowPublicKeyRetrieval 會在某些認(rèn)證方式下報Public Key Retrieval is not allowed。這兩個參數(shù)我每次都會帶上省得排查半天。經(jīng)驗我一般會在連接 URL 里額外加一個connectTimeout5000socketTimeout10000避免數(shù)據(jù)庫掛了之后線程一直卡在等待上壓測時能很快暴露連接超時問題。比如jdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiconnectTimeout5000socketTimeout100002.3 環(huán)境驗證用一個最簡單的查詢打通鏈路驅(qū)動放好、配置想清楚了先做個連通性測試——在 JMeter 里建一個測試計劃加一個 JDBC Connection Configuration再選一個庫建一個線程池跑一條SELECT 1如果返回正常鏈路就通了。這一步別看簡單它價值很大能一次性排除驅(qū)動、URL、賬號密碼、網(wǎng)絡(luò)四個環(huán)節(jié)的問題。如果SELECT 1都跑不通那后面再復(fù)雜的腳本也跑不通不如先在這里把問題解決掉。3. JDBC Connection Configuration連接池配置才是壓測的關(guān)鍵3.1 配置項逐行拆解JDBC Connection Configuration 是 JDBC 請求的前置條件相當(dāng)于給所有 JDBC 請求提供數(shù)據(jù)庫連接池。它不是一個“填個 URL 就行”的簡單配置每個選項背后都有講究。關(guān)鍵的幾個配置項Variable Name for created pool連接池變量名隨便起比如db_pool但你要記死它因為 JDBC Request 里要通過這個名字來引用這個連接池。一個測試計劃里可以配置多個連接池給不同庫用靠名字區(qū)分。Max Number of Connections最大連接數(shù)。這個值很關(guān)鍵它決定了 JMeter 能同時從池里拿多少個連接。如果你壓 100 個并發(fā)但最大連接數(shù)只有 10那 JMeter 的請求就會排隊等連接測出來的結(jié)果不是數(shù)據(jù)庫的真實瓶頸而是連接池的瓶頸。Max Wait最大等待時間單位毫秒。連接池沒空閑連接時請求最多等多久超時拋異常。一般設(shè) 10000。Time Between Eviction Runs清理線程運行間隔。JMeter 會定期清理空閑過久的連接一般設(shè) 60000。Auto Commit自動提交。只做查詢壓測時設(shè) True 就好涉及事務(wù)、插入、更新時按需改成 False。Transaction Isolation事務(wù)隔離級別默認(rèn) DEFAULT 即可不用特別改。Pool Validation Query連接有效性檢查 SQL。MySQL 下寫SELECT 1PostgreSQL 下寫SELECT 1Oracle 下寫SELECT 1 FROM DUAL。JMeter 每次從池里拿連接時可以用這個 SQL 驗證連接是否還活著避免拿到失效連接。3.2 連接池參數(shù)怎么定一個簡單的估算方法連接池最大連接數(shù)怎么定很多教程會說“設(shè)大一點就行”但實際不是這么回事。連接數(shù)設(shè)太大數(shù)據(jù)庫可能會因為并發(fā)連接過多直接拒絕服務(wù)設(shè)太小JMeter 這邊又會排隊。我的做法是連接池最大連接數(shù) 目標(biāo)并發(fā)線程數(shù)。比如你要模擬 100 個用戶并發(fā)那么 Max Number of Connections 就設(shè) 100 或略大于 100比如 100。這樣每個線程拿到一個獨立連接不會出現(xiàn)兩個線程搶一個連接的情況。這里有個容易混淆的細節(jié)JMeter 的線程數(shù)和連接池連接數(shù)不是一一綁定的關(guān)系。線程可以復(fù)用連接但如果你想測的是“數(shù)據(jù)庫在 100 個并發(fā)連接下的表現(xiàn)”那連接數(shù)就必須給夠否則測出來的曲線是連接池排隊曲線不是數(shù)據(jù)庫性能曲線。3.3 為什么要用連接池而不是每個線程單獨連JMeter 里還有一種做法是每個線程自己創(chuàng)建數(shù)據(jù)庫連接不用連接池——比如用 BeanShell 或者 JSR223 寫代碼去DriverManager.getConnection()。我不推薦這種方式做壓測原因有兩個第一性能差。每次請求都重新創(chuàng)建連接開銷全花在 TCP 握手和認(rèn)證上測出來的響應(yīng)時間虛高。第二資源不可控。并發(fā) 100 個線程同時創(chuàng)建 100 個連接壓測機本身的文件描述符、內(nèi)存壓力都會變大干擾結(jié)果。所以標(biāo)準(zhǔn)做法就是一個 JDBC Connection Configuration 管連接池N 個 JDBC Request 從池里取連接執(zhí)行 SQL。連接池的創(chuàng)建、復(fù)用、回收J(rèn)Meter 都在底層幫你處理好了你要做的就是配置好那幾項參數(shù)。4. JDBC Request 詳解增刪改查都能壓4.1 SQL 查詢和變量名規(guī)則JDBC Request 是真正執(zhí)行 SQL 的地方。它長得很像一個 HTTP 請求 Sample但參數(shù)完全不同。核心參數(shù)有三個Variable Name of Pool declared in JDBC Connection Configuration填連接池變量名也就是你在 JDBC Connection Configuration 里填的那個名字。如果這里填錯JMeter 會直接報錯找不到連接池。Query TypeSQL 類型有 Select Statement、Update Statement、Callable Statement、Prepared Select Statement、Prepared Update Statement 等。如果是普通查詢用 Select Statement如果 SQL 里有占位符?必須用 Prepared Select Statement 或 Prepared Update Statement。QuerySQL 語句本體。這里有個新手高頻疑問Query Type 選 Select Statement 和 Prepared Select Statement 有什么區(qū)別區(qū)別在占位符。如果你要執(zhí)行SELECT * FROM user WHERE id ?就必須用 Prepared Select Statement然后通過參數(shù)列表傳入?的值。如果你執(zhí)行的是完整 SQL沒有?用 Select Statement 就行。相同點是結(jié)果都存放在變量里供后續(xù)使用。4.2 查詢結(jié)果的三種用法JDBC Request 執(zhí)行完之后結(jié)果存在哪答案是JMeter 會把結(jié)果集存到變量里變量名規(guī)則是你在 JDBC Request 里填的Variable Name。比如你在 JDBC Request 的 Variable Name 填了mysql_result那么執(zhí)行完查詢后mysql_result整個結(jié)果集mysql_result_#結(jié)果集行數(shù)比如返回 10 行這個變量值就是 10mysql_result_1第一行數(shù)據(jù)mysql_result_1_id第一行的 id 字段值mysql_result_2_id第二行的 id 字段值用Variable Name 下劃線 行號 下劃線 列名這個規(guī)則就能取到任意一行任意一列的值。這個特性相當(dāng)有用。最常見的場景是你從表 A 查到一批訂單 ID然后要把這些 ID 作為參數(shù)傳給下一個 JDBC Request 或 HTTP 請求。具體做法就是先執(zhí)行一條查詢 SQL然后在下一個請求里用${mysql_result_1_id}來引用第一行 ID。4.3 實際案例查詢用戶表數(shù)據(jù)我來演示一個最簡單的例子。假設(shè)數(shù)據(jù)庫里有一張user表字段有id、username、age我想壓測一條查詢 SQLSELECT id, username, age FROM user WHERE age 20配置如下JDBC Request Variable Nameuser_resultQuery TypeSelect StatementQuerySELECT id, username, age FROM user WHERE age 20跑完之后在察看結(jié)果樹里可以看到這個 JDBC Request 的響應(yīng)數(shù)據(jù)里面是查到的所有行。如果你想把這批數(shù)據(jù)取出來給后續(xù)請求用比如遍歷前 10 個用戶 ID就可以用${user_result_1_id}、${user_result_2_id}這種形式去引用。注意結(jié)果集會按位置存儲mysql_result_1是第 1 行mysql_result_2是第 2 行以此類推。如果你查詢結(jié)果本身有排序需求在 SQL 里把ORDER BY寫好否則取出來的行順序可能不穩(wěn)定。4.4 執(zhí)行更新操作怎么配置壓測不光是查詢有時也要模擬寫入、更新的業(yè)務(wù)壓力。比如 100 個用戶同時更新自己的資料。如果是帶參數(shù)的更新比如UPDATE user SET age ? WHERE id ?那么 Query Type 要選Prepared Update StatementSQL 里的?是占位符需要通過“Parameter values”和“Parameter types”傳入實際值。這里有個重要細節(jié)執(zhí)行 Update/Insert/Delete 操作時如果數(shù)據(jù)庫沒有返回結(jié)果集JMeter 會返回受影響的行數(shù)。比如某個 UPDATE 影響了 3 行JMeter 的響應(yīng)數(shù)據(jù)里會顯示3。如果你想驗證更新是否成功一種做法是更新后再執(zhí)行一條 SELECT 去查這條數(shù)據(jù)配合斷言來校驗。5. 參數(shù)化取值讓壓測數(shù)據(jù)動起來5.1 CSVDataset 參數(shù)化每個線程分塊取值做數(shù)據(jù)庫壓測時你常常需要模擬“不同的用戶操作不同的數(shù)據(jù)”而不是 100 個用戶都查同一條記錄。前者才是真實業(yè)務(wù)場景也能更有效地壓出數(shù)據(jù)庫的查詢能力。JMeter 里最常用的參數(shù)化方式就是CSV 數(shù)據(jù)集配置CSV Data Set Config。它允許你從一個 CSV 文件里按行讀取數(shù)據(jù)然后把每一列的值賦給變量。配置的時候有幾點要注意FilenameCSV 文件路徑Variable Names列名用英文逗號分隔比如id,username,ageDelimiter分隔符默認(rèn)是英文逗號Recycle on EOF讀完最后一行后是否回到開頭繼續(xù)讀。如果你壓測時長較長或者并發(fā)數(shù)大于 CSV 行數(shù)建議設(shè) True否則讀到末尾線程會直接結(jié)束或報錯。Stop thread on EOF讀完最后一行是否停止線程。如果 Recycle on EOF 是 True這個就設(shè) False。Sharing mode共享模式。默認(rèn) All threads 是所有線程共享一個文件指針按順序往下讀如果你想每個線程各讀各的可以選 Current thread。我在實際項目里壓“100 并發(fā)用戶登錄”時會準(zhǔn)備一個 100 行的 CSV每行一個用戶 ID 和密碼然后把線程組并發(fā)數(shù)設(shè)為 100CSV 共享模式用默認(rèn)的 All threads這樣每個線程拿到一個不同的用戶數(shù)據(jù)誰也不會搶。5.2 從上一個查詢結(jié)果取參JDBC 請求結(jié)果復(fù)用CSV 適合數(shù)據(jù)預(yù)先準(zhǔn)備好的場景但有些場景數(shù)據(jù)是動態(tài)生成的——你先要查一下有哪些訂單然后針對每個訂單做后續(xù)操作。這種時候就要用 JDBC Request 的查詢結(jié)果來做參數(shù)化。思路是先跑一條 SELECT把結(jié)果存到一個變量里然后在后一個請求里用${var_行號_列名}去引用。舉個例子第一步JDBC Request 查訂單 IDSELECT order_id, amount FROM orders WHERE status pending這個 JDBC Request 的 Variable Name 設(shè)為order_result。第二步在 HTTP 請求或下一個 JDBC Request 里引用訂單 ID${order_result_1_order_id} 訂單金額${order_result_1_amount}這樣就實現(xiàn)了“把數(shù)據(jù)庫查出來的數(shù)據(jù)作為下一個接口的參數(shù)”這個高頻需求。但如果查詢返回了多行而你希望循環(huán)處理每一行數(shù)據(jù)那還是建議配合ForEach 控制器來做。ForEach 控制器可以遍歷一個變量集合比如order_result下的所有行然后逐一執(zhí)行后續(xù)請求。配置時輸入變量前綴order_result循環(huán)變量名隨便取一個比如current_order然后在后續(xù)請求里用${current_order_order_id}就能依次取到每一行的數(shù)據(jù)。5.3 JDBC 請求結(jié)果里的特殊變量行數(shù)和 NULL使用查詢結(jié)果時有兩個場景很容易踩坑。第一空結(jié)果集。如果 SQL 查不到數(shù)據(jù)order_result_#會是 0此時不能引用order_result_1_order_id否則 JMeter 會輸出一個空值。為了不報錯可以搭配If 控制器判斷order_result_#是否大于 0再執(zhí)行后續(xù)邏輯。第二字段值本身是 NULL。比如某個字段在某些行里是 NULL引用之后得到的字符串是null而不是空字符串。如果你的下游接口對參數(shù)格式有嚴(yán)格要求需要在 BeanShell 或 JSR223 里做一個 null 值替換處理否則接口調(diào)用可能會因為多傳了null字符串而報錯。5.4 直接用 JSR223 腳本搞定更復(fù)雜的數(shù)據(jù)加工如果上面的方式都滿足不了需求比如你要對查出來的數(shù)據(jù)進行 MD5 加密后作為參數(shù)傳給接口那就得上 JSR223 腳本了。JSR223 Sampler 里可以用 Groovy 直接查數(shù)據(jù)庫處理結(jié)果集生成任意格式的字符串。Groovy 的語法比 BeanShell 簡潔太多性能也更好是 JMeter 官方推薦的方式。雖然這篇文章主要講 JDBC Request 這種圖形化配置但在自定義邏輯非常復(fù)雜的時候JSR223 是終極兜底方案。簡單示例import java.sql.* // 獲取連接池里的連接 def conn vars.get(db_pool) // 這只是示意 // 真實的連接獲取可以通過 DataSource 或者直接用 JDBC 驅(qū)動獲取這里省略不過說實話只有你需要寫復(fù)雜邏輯時才用 JSR223一般情況下 JDBC Request CSV 已經(jīng)能覆蓋絕大多數(shù)場景。過度使用 JSR223 反而會讓腳本難以維護。6. 斷言校驗怎么證明數(shù)據(jù)庫返回是對的6.1 響應(yīng)斷言最快最直接的校驗方式壓數(shù)據(jù)庫不是把 SQL 跑完就完事了你得確認(rèn)返回內(nèi)容是符合預(yù)期的。比如你查詢age 20的用戶結(jié)果返回里至少有數(shù)據(jù)行而不是空結(jié)果集或者一堆錯誤信息。JMeter 的響應(yīng)斷言可以加到 JDBC Request 上用來校驗響應(yīng)內(nèi)容。配置方式很簡單在 JDBC Request 上右鍵 → Add → Assertions → Response AssertionField to Test選 Text ResponsePattern Matching Rules選 ContainsPatterns to Test填你要校驗的關(guān)鍵字比如查詢user表你想確認(rèn)結(jié)果里有username這個字段名就可以在響應(yīng)斷言里填username。如果響應(yīng)里沒有這個關(guān)鍵字?jǐn)嘌跃蜁≡诰酆蠄蟾胬飼吹藉e誤率上升。這里有個技巧有時候 SQL 查出來的數(shù)據(jù)量很大響應(yīng)內(nèi)容很長你沒法直觀地看到是否有數(shù)據(jù)這時可以直接用響應(yīng)斷言校驗 “返回行數(shù)不為 0”。具體做法是把 SQL 改成SELECT COUNT(*) AS cnt FROM user WHERE age 20然后斷言響應(yīng)里包含cnt10或某個具體數(shù)字。注意JMeter 響應(yīng)里 COUNT 查詢的顯示格式是類似cnt10這樣的配合 Contains 斷言就能判斷數(shù)據(jù)量是否符合預(yù)期。6.2 BeanShell 斷言處理復(fù)雜校驗邏輯響應(yīng)斷言只能做簡單匹配如果你要做復(fù)雜判斷比如“查詢結(jié)果里最大金額大于 1000”或“返回行數(shù)在某個區(qū)間內(nèi)”就得用 BeanShell 斷言或者 JSR223 斷言。JSR223 斷言可以用 Groovy 寫邏輯清晰多了。比如判斷結(jié)果集行數(shù)def rowCount vars.get(user_result_#).toInteger() if (rowCount 10) { // 失敗手動設(shè)置斷言結(jié)果 AssertionResult.setFailure(true) AssertionResult.setFailureMessage(查詢結(jié)果集行數(shù)小于10實際為: rowCount) }這段腳本的邏輯是從 JMeter 變量里取user_result_#的值轉(zhuǎn)成整數(shù)判斷是否小于 10如果小于就手動標(biāo)記斷言失敗并輸出失敗原因。這樣在聚合報告或察看結(jié)果樹里你能很直觀地看到哪些請求沒通過校驗。經(jīng)驗斷言別加太多加的每一個斷言都會消耗額外的性能。壓測腳本里的斷言越精簡越好能用一個響應(yīng)斷言解決的就不要加腳本斷言。高并發(fā)壓測時過重的斷言會拉高 JMeter 本身的 CPU 開銷影響測試數(shù)據(jù)準(zhǔn)確性。6.3 結(jié)合“用結(jié)果樹看數(shù)據(jù)”排查問題壓測跑完后第一件事永遠是看察看結(jié)果樹View Results Tree。在結(jié)果樹里每個 JDBC Request 都能展開看它的請求數(shù)據(jù)、響應(yīng)數(shù)據(jù)、斷言結(jié)果。響應(yīng)數(shù)據(jù)里會顯示 SQL 執(zhí)行后返回的內(nèi)容格式。我遇到過很多測試小白寫完了腳本直接開壓壓完發(fā)現(xiàn)錯誤率 100%然后開始懷疑數(shù)據(jù)庫出問題了。其實根本不是數(shù)據(jù)庫的問題而是 SQL 寫錯了或者參數(shù)沒傳進去。這種時候不用慌打開察看結(jié)果樹找一個失敗的請求看它的響應(yīng)數(shù)據(jù)里的報錯信息十有八九一次就能定位到問題。7. 并發(fā)壓測實戰(zhàn)模擬 100 個用戶同時查庫7.1 線程組參數(shù)設(shè)計前面把 JDBC Request 和參數(shù)化都講完了接下來進入實戰(zhàn)模式——模擬 100 個用戶同時訪問數(shù)據(jù)庫看數(shù)據(jù)庫的表現(xiàn)。線程組配置建議Number of Threads (users)100Ramp-Up Period (seconds)10Loop Count50 或者填 ∞根據(jù)你的壓測時長來定這里解釋一下 Ramp-Up Period 的作用它表示 100 個線程在 10 秒內(nèi)全部啟動完畢也就是說每秒啟動 10 個線程。這樣做是為了模擬用戶逐步進入系統(tǒng)的真實場景而不是 100 個請求在同一毫秒內(nèi)全部打到數(shù)據(jù)庫。如果你希望一開始就是滿負(fù)載可以把 Ramp-Up 設(shè)成 1 秒如果你要做階梯壓測可以用 Stepping Thread Group 插件但這個插件需要額外安裝基礎(chǔ)場景下普通線程組就夠用了。Loop Count 表示每個線程執(zhí)行多少次查詢。假如一個 JDBC Request 執(zhí)行一條 SQL100 個線程 × 循環(huán) 50 次 總共 5000 次 SQL 查詢。這個總數(shù)可以用來估算壓測時長和數(shù)據(jù)庫負(fù)載。7.2 實戰(zhàn)腳本結(jié)構(gòu)一個標(biāo)準(zhǔn)的數(shù)據(jù)庫壓測腳本結(jié)構(gòu)如下測試計劃線程組100 線程10 秒內(nèi)啟動JDBC Connection Configuration連接池配置最大連接數(shù) 100CSV Data Set Config用戶數(shù)據(jù)參數(shù)化JDBC Request執(zhí)行 SQL響應(yīng)斷言校驗返回結(jié)果監(jiān)聽器聚合報告Aggregate Report察看結(jié)果樹View Results Tree需要注意JDBC Connection Configuration 和 CSV Data Set Config 都是配置元件Config Element它們的作用范圍是“所在層級之下的所有請求”。放在線程組下就對該線程組里的所有 JDBC Request 生效。7.3 壓測過程中的實時監(jiān)控壓測跑起來之后除了看 JMeter 的聚合報告我強烈建議你同時監(jiān)控數(shù)據(jù)庫端的指標(biāo)。光看 JMeter 的響應(yīng)時間是不夠的你還需要知道數(shù)據(jù)庫的 CPU、內(nèi)存、連接數(shù)、慢查詢數(shù)等指標(biāo)才能完整評估數(shù)據(jù)庫性能。具體做法如果是 MySQL可以在壓測時執(zhí)行SHOW PROCESSLIST;查看當(dāng)前所有連接和正在執(zhí)行的 SQL。查看數(shù)據(jù)庫的 CPU 和內(nèi)存占用比如用top或數(shù)據(jù)庫自帶的性能監(jiān)控工具。開啟慢查詢?nèi)罩緣簻y完后分析哪些 SQL 的執(zhí)行時間超過了閾值。這一步非常重要因為 JMeter 的聚合報告只能告訴你“響應(yīng)時間變慢了”但到底慢在數(shù)據(jù)庫的哪個環(huán)節(jié)——是 CPU 打滿了、還是鎖等待、還是磁盤 IO——必須結(jié)合數(shù)據(jù)庫端的指標(biāo)來看。7.4 聚合報告怎么解讀壓測結(jié)束看聚合報告的幾個核心指標(biāo)Samples總請求數(shù)Average平均響應(yīng)時間單位毫秒Min / Max最小/最大響應(yīng)時間Std. Dev.響應(yīng)時間標(biāo)準(zhǔn)差越大說明響應(yīng)時間波動越明顯性能越不穩(wěn)定Error %錯誤率正常壓測場景下應(yīng)為 0%有少量錯誤要具體分析Throughput吞吐量單位通常是req/sec意思是每秒能處理多少請求舉個例子100 個線程、循環(huán) 50 次的腳本跑完Samples 是 5000Throughput 如果是 200/sec說明數(shù)據(jù)庫每秒能扛住 200 次這個 SQL 查詢。如果你把循環(huán)次數(shù)加大Throughput 會逐步逼近數(shù)據(jù)庫的極限值這個極限值就是數(shù)據(jù)庫的處理能力上限。經(jīng)驗壓測數(shù)據(jù)庫時平均響應(yīng)時間和吞吐量要一起看。如果平均響應(yīng)時間很低但吞吐量也低說明 JMeter 本身或網(wǎng)絡(luò)成了瓶頸不是數(shù)據(jù)庫不行如果吞吐量上去了但平均響應(yīng)時間也跟著飆升這才說明數(shù)據(jù)庫開始進入高負(fù)載狀態(tài)。8. 常見問題與排查技巧實錄8.1 連接不通ClassNotFoundException 和 URL 報錯問題現(xiàn)象JDBC Request 報ClassNotFoundException: com.mysql.jdbc.Driver或Cannot create PoolableConnectionFactory。排查思路先看驅(qū)動 Jar 包有沒有放到 JMeter 的 lib 目錄下然后看是否重啟了 JMeter。如果確定 Jar 包在再看 Driver Class 寫對沒有——MySQL 8.x 驅(qū)動對應(yīng)的是com.mysql.cj.jdbc.Driver不是com.mysql.jdbc.Driver。如果報錯信息是Unknown database xxx檢查連接 URL 里的數(shù)據(jù)庫名是否正確。如果是Access denied for user檢查賬號密碼和數(shù)據(jù)庫權(quán)限。8.2 連接池不夠用Too many connections問題現(xiàn)象壓測過程中JMeter 報Too many connections或者數(shù)據(jù)庫端出現(xiàn)Connection refused。原因分析這個報錯有兩個方向一個是 JMeter 連接池最大連接數(shù)設(shè)得太大打爆了數(shù)據(jù)庫的最大連接數(shù)另一個是數(shù)據(jù)庫自身max_connections配置太小。解決方案先查看數(shù)據(jù)庫的max_connections比如 MySQL 可以用SHOW VARIABLES LIKE max_connections;查看。然后調(diào)整 JMeter 連接池的最大連接數(shù)讓它的上限略低于數(shù)據(jù)庫的max_connections留一些余量給其他應(yīng)用連接。順便說一句做壓測之前一定要和 DBA 或運維確認(rèn)好數(shù)據(jù)庫的連接上限否則壓到一半數(shù)據(jù)庫直接把連接全踢掉測試結(jié)果就廢了。8.3 響應(yīng)時間異常長慢 SQL 還是連接池排隊問題現(xiàn)象聚合報告顯示平均響應(yīng)時間高達幾秒遠大于你手動執(zhí)行 SQL 的時間。原因分析首先要區(qū)分是數(shù)據(jù)庫真慢還是連接池在排隊。手動執(zhí)行 SQL 快說明 SQL 本身沒問題。這時候要去看 JMeter 連接池的最大連接數(shù)是不是小于線程數(shù)——如果 100 個線程去搶 20 個連接剩下 80 個線程全在等連接響應(yīng)時間自然飆升。解決方案把 Max Number of Connections 調(diào)大使其等于或大于線程數(shù)再跑一次對比。如果響應(yīng)時間正常了說明之前的瓶頸是連接池如果響應(yīng)時間依然很大那就要去數(shù)據(jù)庫端看慢查詢?nèi)罩径ㄎ皇遣皇撬饕А㈡i等待等問題。還有一個細節(jié)如果連接 URL 設(shè)置了socketTimeout當(dāng)數(shù)據(jù)庫處理查詢超過這個值時JMeter 會直接報 socket 超時。這種情況下不是數(shù)據(jù)庫變慢而是策略性地斷開了連接。壓測時可以把 socketTimeout 調(diào)大一點避免誤判。8.4 變量引用出來是 null結(jié)果集行號與字段大小寫問題現(xiàn)象在后續(xù)請求里用${var_1_id}引用 JDBC 查詢結(jié)果發(fā)現(xiàn)值是 null 或者空字符串。原因排查第一先看結(jié)果集是不是空的。如果 SQL 查不出來數(shù)據(jù)任何引用都是空。用察看結(jié)果樹看響應(yīng)數(shù)據(jù)確認(rèn)是否有數(shù)據(jù)返回。第二看字段名大小寫。MySQL 的字段名默認(rèn)全小寫如果 SQL 里寫了別名比如SELECT id AS userId FROM user那么引用時要寫成${var_1_userId}。建議 SQL 里起別名時統(tǒng)一用帶下劃線的命名如user_id然后引用時保持大小寫一致。第三行號從 1 開始不是從 0 開始。如果變量名是order_result那么第一行是order_result_1沒有order_result_0這個變量。8.5 中文亂碼與編碼問題問題現(xiàn)象JDBC 查詢返回的中文變成問號或亂碼。原因排查大多是連接 URL 里沒有指定字符集。在 MySQL 連接 URL 上加上characterEncodingutf8jdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaicharacterEncodingutf8另外檢查數(shù)據(jù)庫表本身的字符集是不是 utf8mb4。如果表是 latin1 而應(yīng)用按 utf8 讀取也會亂碼。8.6 一個容易被忽略的問題壓測機性能不夠最后提一個很多人踩過的坑——壓測機本身的性能不夠。JMeter 是 Java 應(yīng)用100 個并發(fā)線程跑起來時壓測機 CPU 和內(nèi)存消耗不小。如果你在本地筆記本上壓遠程數(shù)據(jù)庫壓測結(jié)果可能不是你 SQL 的真實性能而是筆記本 CPU 打滿后的結(jié)果。怎么判斷壓測時打開任務(wù)管理器或top看看 Java 進程的 CPU 占用率。如果已經(jīng)超過了機器 CPU 的 70% 以上建議換一臺性能更強的機器或者把 JMeter 部署到另一臺服務(wù)器上盡量讓壓測機資源充足確保瓶頸在數(shù)據(jù)庫端而不是客戶端。8.7 問題排查速查表問題現(xiàn)象可能原因解決方案ClassNotFoundException驅(qū)動 Jar 未放到 lib 目錄放入 Jar 包并重啟 JMeterCannot create PoolableConnectionFactoryURL 或賬號密碼錯誤檢查 URL 格式、賬號權(quán)限Too many connections連接數(shù)超過數(shù)據(jù)庫上限調(diào)大數(shù)據(jù)庫 max_connections 或調(diào)小 JMeter 連接池響應(yīng)時間超長連接池排隊或慢 SQL調(diào)大連接池查看慢查詢?nèi)罩咀兞恐禐?null結(jié)果集為空或字段名大小寫不一致確認(rèn)查詢結(jié)果檢查 SQL 別名中文亂碼連接 URL 未指定字符集添加 characterEncodingutf8壓測結(jié)果不穩(wěn)定壓測機資源不足更換壓測機或降低線程數(shù)9. 一個完整的數(shù)據(jù)庫壓測腳本示例講了這么多最后給你一個完整的 MySQL 壓測腳本搭建過程從零到一可以直接照抄。9.1 測試場景模擬 100 個用戶并發(fā)查詢訂單表每個查詢根據(jù)不同的訂單 ID 查詢訂單信息持續(xù)壓測 10 分鐘觀察數(shù)據(jù)庫的吞吐量和響應(yīng)時間變化。9.2 準(zhǔn)備工作MySQL 數(shù)據(jù)庫提前創(chuàng)建好訂單表orders字段包括order_id、user_id、amount、status準(zhǔn)備一個order_ids.csv文件里面放 100 個訂單 ID用于參數(shù)化JMeter 5.xmysql-connector-java-8.0.x.jar已放入 lib 目錄并重啟9.3 腳本搭建步驟第一步創(chuàng)建測試計劃并添加線程組線程數(shù) 100Ramp-Up 10 秒循環(huán)次數(shù)勾選無限在調(diào)度器配置里設(shè)置持續(xù)時間為 600 秒。第二步添加 JDBC Connection Configuration配置項如下Variable Name for created poolmysql_poolMax Number of Connections100Max Wait10000Auto CommitTruePool Validation QuerySELECT 1Database Connection ConfigurationDatabase URLjdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiJDBC Driver Classcom.mysql.cj.jdbc.DriverUsernametest_userPasswordyour_password第三步添加 CSV Data Set ConfigFilename/data/order_ids.csvVariable Namesorder_idDelimiter,Recycle on EOFTrueStop thread on EOFFalseSharing modeAll threads第四步添加 JDBC RequestVariable Name of Poolmysql_poolQuery TypePrepared Select StatementQuerySELECT * FROM orders WHERE order_id ?Parameter values${order_id}Parameter typesVARCHAR這里說明一下因為 SQL 里有?占位符所以 Query Type 必須選 Prepared Select StatementParameter values 里填 CSV 讀取出來的訂單 IDParameter types 填數(shù)據(jù)庫字段類型。第五步添加響應(yīng)斷言Field to TestText ResponsePattern Matching RulesContainsPatterns to Testorder_id這樣就確保了查詢請求返回的結(jié)果中包含 order_id 字段證明查詢是成功的。第六步添加監(jiān)聽器加一個聚合報告和一個察看結(jié)果樹。壓測結(jié)束后聚合報告里可以看到平均響應(yīng)時間、吞吐量、錯誤率等核心數(shù)據(jù)。9.4 跑完怎么分析壓測結(jié)束后我一般這么看數(shù)據(jù)先看錯誤率。如果錯誤率為 0%說明 100 并發(fā)下這條 SQL 沒有出錯數(shù)據(jù)庫連接和查詢都正常。如果錯誤率大于 0查詢具體的錯誤信息常見的是連接池不夠用或超時。然后看吞吐量變化。如果 JMeter 的 Throughput 在持續(xù)穩(wěn)定上升后趨于平緩說明已經(jīng)摸到了數(shù)據(jù)庫的處理上限。此時如果平均響應(yīng)時間還能接受說明數(shù)據(jù)庫還有冗余如果響應(yīng)時間已經(jīng)超標(biāo)比如超過 500ms說明數(shù)據(jù)庫快要撐不住了。最后結(jié)合數(shù)據(jù)庫端監(jiān)控比如 CPU、慢查詢?nèi)罩究雌款i到底在哪個環(huán)節(jié)然后給出測試結(jié)論和優(yōu)化建議。這里有一個小建議壓測時先把線程數(shù)保守一點比如 50跑一輪看結(jié)果再逐步升到 100、200。這樣做的好處是你能看到數(shù)據(jù)庫在不同并發(fā)下的表現(xiàn)曲線而不是一上來就壓到天花板拿到一堆根本沒法分析的數(shù)據(jù)。階梯式加壓是我在實際項目中比較喜歡用的方式。最后說幾句實在話用 JMeter 做數(shù)據(jù)庫壓測門檻真的不高但想做好需要你對數(shù)據(jù)庫本身的運行機制有基本認(rèn)知。我在實際測試項目里見過不少人把壓測腳本配好了、跑出了漂亮的報告但一問數(shù)據(jù)庫端的指標(biāo)完全答不上來——CPU 多少、內(nèi)存多少、慢查詢有沒有、連接數(shù)有沒有到上限全是空白。這種壓測報告說實話價值有限。我的個人建議是壓測數(shù)據(jù)庫永遠要把 JMeter 端的數(shù)據(jù)和數(shù)據(jù)庫端的數(shù)據(jù)結(jié)合起來看。JMeter 告訴你發(fā)生了什么數(shù)據(jù)庫的監(jiān)控告訴你為什么會發(fā)生。兩邊對照才能真正判斷數(shù)據(jù)庫的性能瓶頸在哪里也才能給出可信的測試結(jié)論。如果你只是剛接觸這塊先從最簡單的單條 SQL 查詢壓測入手把 JDBC Connection Configuration 和 JDBC Request 玩熟再慢慢加參數(shù)化、加斷言、加并發(fā)場景。不要一上來就想測多表關(guān)聯(lián)或存儲過程底子打好后面的內(nèi)容都是水到渠成的事。