原文由zlulu發(fā)表于TesterHome社區(qū)，原文鏈接

緣起

前段時(shí)間，我負(fù)責(zé)測(cè)試的系統(tǒng)在生產(chǎn)環(huán)境運(yùn)行出現(xiàn)問(wèn)題。該系統(tǒng)對(duì)于響應(yīng)時(shí)間要求較高，問(wèn)題發(fā)生的時(shí)候并發(fā)很高，出現(xiàn)大量請(qǐng)求超時(shí)，超時(shí)請(qǐng)求比例隨時(shí)間推遲越來(lái)越高，最后幾乎全部請(qǐng)求都失敗。滾動(dòng)重啟了所有進(jìn)程后，很快又出現(xiàn)超時(shí)情況。
后經(jīng)過(guò)排查，發(fā)現(xiàn)是新版本實(shí)現(xiàn)某個(gè)功能時(shí)修改了一個(gè)數(shù)據(jù)庫(kù)查詢語(yǔ)句，修改后該查詢語(yǔ)句的查詢條件未使用到索引字段，而所查詢的表生產(chǎn)環(huán)境中體量巨大，因此這個(gè)查詢操作耗時(shí)從毫秒級(jí)變成了秒級(jí)，也就是形成了所謂的慢查詢，再加上大量并發(fā)，悲劇就發(fā)生了。
事件發(fā)生后，我們測(cè)試團(tuán)隊(duì)進(jìn)行了反思，這么嚴(yán)重的問(wèn)題為何測(cè)試環(huán)境沒有發(fā)現(xiàn)？總結(jié)了兩點(diǎn)原因，一是，測(cè)試環(huán)境進(jìn)行功能測(cè)試時(shí)并發(fā)量不高，即使單個(gè)請(qǐng)求變慢也不會(huì)發(fā)生超時(shí)現(xiàn)象；二是，測(cè)試環(huán)境數(shù)據(jù)庫(kù)表的數(shù)據(jù)量較生產(chǎn)環(huán)境小很多，所以單個(gè)查詢操作比生產(chǎn)快很多，這樣壓力測(cè)試中請(qǐng)求也極少超時(shí)。

求索

綜上所述，想要在測(cè)試過(guò)程中人為識(shí)別一個(gè)慢查詢很難，為了杜絕這類問(wèn)題再次發(fā)生，在后續(xù)版本測(cè)試中我們做了一些嘗試。
因?yàn)槲覀儍?nèi)部本來(lái)就有使用代碼掃描的工具，每個(gè)版本都會(huì)通過(guò)掃描來(lái)識(shí)別一些問(wèn)題，所以我們首先想到了通過(guò)靜態(tài)掃描原代碼，撈出所有的數(shù)據(jù)庫(kù)查詢語(yǔ)句然后進(jìn)行分析。實(shí)際操作后發(fā)現(xiàn)，我們系統(tǒng)在數(shù)據(jù)庫(kù)操作上大量使用框架，不同模塊使用的框架還不同，撈出的數(shù)據(jù)庫(kù)語(yǔ)句千奇百怪，且包含代碼元素，并不是能直接執(zhí)行的語(yǔ)句，對(duì)于大型系統(tǒng)而言，人工去分析這些語(yǔ)句工作量太大，這種方法并不可行。
然后我們想到，可以從數(shù)據(jù)庫(kù)側(cè)來(lái)解決這個(gè)問(wèn)題，通過(guò)開啟 Mysql 的慢查詢?nèi)罩鹃_關(guān)，將功能測(cè)試過(guò)程中大于 long_query_time 配置時(shí)間的數(shù)據(jù)庫(kù)查詢操作都記錄下來(lái)，再逐個(gè)分析是否存在慢查詢問(wèn)題。過(guò)程中我們確實(shí)抓到了很多執(zhí)行較慢的查詢語(yǔ)句，但經(jīng)過(guò)分析后發(fā)現(xiàn)，這些語(yǔ)句絕大部分都是測(cè)試人員人工查詢數(shù)據(jù)庫(kù)的操作，更遺憾的是，由于測(cè)試數(shù)據(jù)數(shù)量級(jí)較少，之前發(fā)生生產(chǎn)問(wèn)題的查詢語(yǔ)句在測(cè)試環(huán)境的執(zhí)行時(shí)間并沒有超過(guò) long_query_time，由此并不能被識(shí)別出來(lái)。由此可見，這種方法誤報(bào)和漏報(bào)概率很大，也不可行。

革新

現(xiàn)有工具無(wú)法滿足我們識(shí)別慢查詢語(yǔ)句的需求，于是我們決定自己做了一套工具。通過(guò)大量的分析和實(shí)驗(yàn)，我們得到了一個(gè)高效、準(zhǔn)確性、且通用性極好的解決方案：

?

經(jīng)過(guò)分析，識(shí)別慢查詢語(yǔ)句需要解決兩個(gè)問(wèn)題：一是，如何獲得系統(tǒng)執(zhí)行是查詢語(yǔ)句；二是，如何分析某個(gè)查詢是否是慢查詢。
解決第一個(gè)問(wèn)題，我們想到了使用插樁技術(shù)。
對(duì)于一個(gè)查詢操作，不管上層應(yīng)用代碼如何編寫、或使用何種數(shù)據(jù)庫(kù)框架，這個(gè)操作最終會(huì)與目標(biāo)數(shù)據(jù)庫(kù)交互，而交互的時(shí)候它一定必須是一個(gè)標(biāo)準(zhǔn)的 SQL 語(yǔ)句。基于這一點(diǎn)，我們對(duì)這個(gè)應(yīng)用進(jìn)行了全面的分析，我們的系統(tǒng)部署在 Jboss 上，通過(guò)層層剖析，我們找到了這個(gè)實(shí)際執(zhí)行查詢操作數(shù)據(jù)庫(kù)交互的方法，位于 Jboss 的 JCA 包中，共用到以下兩處：

① org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery() ② org.jboss.jca.adapters.jdbc.WrappedStatement.executeQuery()

通過(guò)大量的實(shí)驗(yàn)，我們確定我們這個(gè)系統(tǒng)所有數(shù)據(jù)庫(kù)查詢操作必定會(huì)調(diào)用①②中的一個(gè)來(lái)完成（實(shí)現(xiàn)邏輯不同其他系統(tǒng)可能調(diào)用的是 JCA 的其他方法）。再通過(guò)在①②設(shè)置斷點(diǎn) bebug 我們發(fā)現(xiàn)，在①②方法內(nèi)部 SQL 語(yǔ)句是完全可見的。
接下來(lái)我們利用的 Java Instrument Api 及其衍生的開源組件，搭建了一個(gè) agent 程序。啟動(dòng) agent，agent 在應(yīng)用系統(tǒng)程序運(yùn)行時(shí)動(dòng)態(tài)的往這兩個(gè)地方分別插個(gè)樁，樁的內(nèi)容非常簡(jiǎn)單：將當(dāng)前方法體內(nèi)存中正在執(zhí)行的 SQL 語(yǔ)句打印到某個(gè)固定位置（假設(shè)我們把 SQL 語(yǔ)句輸出到日志文件 A 中）。相對(duì)于在①②方法體內(nèi)部多寫一句 print，僅僅只做一個(gè)打印的操作，不會(huì)對(duì)業(yè)務(wù)邏輯產(chǎn)生任何干擾。
于是我們就完成了這樣一個(gè)事情：當(dāng)應(yīng)用系統(tǒng)要進(jìn)行數(shù)據(jù)庫(kù)查詢操作時(shí)，它會(huì)調(diào)用①②中的一個(gè)來(lái)執(zhí)行這個(gè)查詢 SQL，①②被調(diào)用時(shí)，會(huì)將正在執(zhí)行的 SQL 語(yǔ)句輸出到日志文件 A 中。這樣，每一個(gè)查詢操作，都會(huì)將實(shí)際的查詢語(yǔ)句記錄在日志文件 A 中，也就完成了查詢語(yǔ)句的收集啦。
通過(guò)插樁我們獲得了大量的 SQL 語(yǔ)句，接下來(lái)解決第二個(gè)問(wèn)題，如何判斷一個(gè)查詢語(yǔ)句是否為慢查詢。
由于測(cè)試和生產(chǎn)數(shù)據(jù)數(shù)量級(jí)的差異，用執(zhí)行時(shí)間來(lái)判斷顯然不科學(xué)。同時(shí)，我們一共獲得了幾萬(wàn)條 SQL 語(yǔ)句，直接進(jìn)行人工分析顯然不可行。
我們想到了 Mysql 提供的 explain 命令來(lái)擴(kuò)展 SQL 語(yǔ)句，通過(guò) Mysql 的執(zhí)行計(jì)劃來(lái)科學(xué)判斷執(zhí)行的快慢。每條可執(zhí)行 SQL 語(yǔ)句都可以直接用 explain 命令獲得

?

執(zhí)行計(jì)劃中的每一個(gè)列標(biāo)簽都可以作為匹配環(huán)節(jié)的關(guān)注項(xiàng)，我們稱其為指標(biāo)項(xiàng)，我們用到了與查詢效率相關(guān)的指標(biāo)項(xiàng)中最重要的兩個(gè)：
1、key：表示這個(gè) SQL 語(yǔ)句執(zhí)行時(shí)會(huì)使用的索引的鍵；
2、type：訪問(wèn)方式，表示執(zhí)行 SQL 語(yǔ)句是在數(shù)據(jù)庫(kù)表中找到所需行的方式，可能的值如下：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

從 system 到 ALL，性能從好到差，一般來(lái)說(shuō)應(yīng)保證至少達(dá)到 range 級(jí)別。
第一步，我們將日志文件 A 中所有的 SQL 語(yǔ)句逐條轉(zhuǎn)換成執(zhí)行計(jì)劃；
第二步，根據(jù)系統(tǒng)實(shí)際需求，建立一套規(guī)則，對(duì)執(zhí)行計(jì)劃進(jìn)行篩選，找出可能是慢查詢的語(yǔ)句；
我們系統(tǒng)匹配慢查詢的規(guī)則是：

key in [NULL] OR type in [range,index,ALL] OR Rows >= 1000

這個(gè)規(guī)則表示：如果一個(gè) SQL 語(yǔ)句它未經(jīng)過(guò)索引、或者訪問(wèn)方式為 range、index、ALL 之一、或者預(yù)估掃描行數(shù)大于等于 1000 條，那么它可能是一個(gè)慢查詢。
第三步，對(duì)可能是慢查詢的語(yǔ)句進(jìn)行人工分析。
通過(guò)第二步的篩選，我們將需要分析的 SQL 語(yǔ)句數(shù)量從幾十萬(wàn)條降到了十幾條，后續(xù)再人工逐一分析。
如此，我們完成了系統(tǒng)的慢查詢測(cè)試工作。之前導(dǎo)致生產(chǎn)問(wèn)題的 SQL 語(yǔ)句完美命中，其他疑似慢查詢語(yǔ)句結(jié)合查詢頻率、生產(chǎn)數(shù)據(jù)表數(shù)量級(jí)等因素，人工判定為非慢。

破浪

后來(lái)，通過(guò)實(shí)現(xiàn) agent 插樁位置、慢查詢篩選規(guī)則的可配置，我們將這套解決方案優(yōu)化為一個(gè)通用框架，并推廣到部門的多個(gè)系統(tǒng)使用，并發(fā)現(xiàn)了若干慢查詢隱患。
對(duì)于這套基于插樁的慢查詢測(cè)試方法，總結(jié)優(yōu)勢(shì)如下：
1、SQL 語(yǔ)句覆蓋全面，且準(zhǔn)確性較高。只有插樁點(diǎn)分析準(zhǔn)備，可以保證捕獲程序運(yùn)行時(shí)執(zhí)行的所有 SQL 語(yǔ)句（由于實(shí)際執(zhí)行過(guò)的 SQL 語(yǔ)句才能被捕獲，因此依賴于功能測(cè)試的完整性），而以執(zhí)行計(jì)劃為基礎(chǔ)的分析更具有科學(xué)性，且不受數(shù)據(jù)量大小的影響，準(zhǔn)確性更高。
2、有極好的通用性。插樁位置可配置，不同系統(tǒng)只需修改配置既能使用。樁點(diǎn)一般為底層實(shí)現(xiàn)與數(shù)據(jù)庫(kù)交互的數(shù)據(jù)庫(kù)驅(qū)動(dòng)包某一些特定的類和方法，與具體應(yīng)用程序?qū)崿F(xiàn)方式不相關(guān)，也就是說(shuō)，無(wú)論程序功能是什么、無(wú)論使用了什么數(shù)據(jù)庫(kù)框架，只要配置正確的數(shù)據(jù)庫(kù)交互類及其方法，都能適配。
3、非侵入、可插拔，被測(cè)應(yīng)用無(wú)感知。agent 啟動(dòng)，則動(dòng)態(tài)插樁，agent 停止，則樁點(diǎn)消失。無(wú)需對(duì)被測(cè)應(yīng)用源碼做任何修改，檢測(cè)過(guò)程對(duì)功能無(wú)影響，可在功能測(cè)試中悄無(wú)聲息的完成。

---

收獲前沿測(cè)試開發(fā)技術(shù) ·?學(xué)習(xí)先進(jìn)質(zhì)量管理辦法 · 結(jié)識(shí)測(cè)試大咖和行業(yè)精英?↓↓↓↓?

??

總結(jié)

以上是生活随笔為你收集整理的使用插桩技术解决慢查询测试问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。