TOP SQL，是 DBA 經常需要關注的語句，這些語句往往是執(zhí)行頻次高、執(zhí)行時間長、資源開銷高的語句。這些語句也成為 DBA 優(yōu)化的重點。但這里有一個問題就是，上述這些語句真的是需要優(yōu)化的嗎？其實，針對這些語句如果是穩(wěn)態(tài)運行的話，是不需要太多關注的，因為它們不會成為未來影響穩(wěn)定運行的“X 因素”，反而是哪些不穩(wěn)定的、即將變差的、存在毛刺的等語句反而是需要更多關注的。然后我們在各種常規(guī)的監(jiān)控平臺、工具上通常只能看到前者這些語句，而針對后者這些語句反而無從下手。本文就是嘗試從另一個角度入手，通過 DeepSeek 對語句執(zhí)行的日志進行分析，將原來需要繁瑣的程序處理簡化到不用寫代碼，簡單文字交互處理即可。

一、環(huán)境準備：模擬日志+文字交互

這里簡化測試環(huán)境，使用 BenchMark 數(shù)據(jù)作為基礎數(shù)據(jù)。一方面通過自己寫的小程序，模擬應用定時執(zhí)行指定SQL；另一方面通過執(zhí)行 BenchMark 增加環(huán)境噪聲。針對上面的執(zhí)行結果記錄到日志文件中，記錄的信息是執(zhí)行時間和SQL執(zhí)行時長。這里執(zhí)行了兩組，一組是單獨執(zhí)行SQL，一組是在執(zhí)行過程中增加了環(huán)境負載的情況，分別對應兩個輸出的日志文件，并上傳給 DeepSeek。

提示詞

上傳文件是兩組時序數(shù)據(jù)，針對這些數(shù)據(jù)進行分析并圖形化展示。

1.時序數(shù)據(jù)格式

1).數(shù)據(jù)使用逗號分隔

2).第一列含義為SQL語句的執(zhí)行時間，第二列為SQL語句的執(zhí)行時長

2.圖形化輸出要求

1).格式為HTML

2).輸出的HTML代碼中包含完整的數(shù)據(jù)

3).輸出圖形沾滿整個窗口

4).采用光滑折線圖方式

5).針對兩組數(shù)據(jù)上下分列顯示并采用相同的量程

3.數(shù)據(jù)分析要求

1).輸出SQL的執(zhí)行情況

從上面圖中可以看到，第一組數(shù)據(jù)SQL執(zhí)行較為平滑（如上圖），第二組數(shù)據(jù)SQL執(zhí)行較為陡峭（如下圖）；其原因是在第二組執(zhí)行過程中，中間施加了一些環(huán)境干擾，導致語句執(zhí)行時間增長。

二、了解整體執(zhí)行情況 — 統(tǒng)計分析

我們先整體了解下運行情況，這里可利用一些標準的統(tǒng)計函數(shù)來完成，交給 DeepSeek 看看情況如何？

提示詞

針對上面第二組數(shù)據(jù)，使用Python3分析其SQL語句執(zhí)行特征，以圖形化的方式輸出，包括但不限于執(zhí)行時長的平均值、中位線等指標

從這里可以看出信息量還是很豐富的，不僅包含了運行時長、平均值、中位數(shù)等常規(guī)的，還包括了密度分布、箱式圖（后文會講）等內容。從中我們可以觀察到一些情況，例如平均值>中位數(shù)，這表明存在右偏分布（少量高耗時查詢拉高均值）。再例如執(zhí)行時長密度分布存在雙峰現(xiàn)象，說明存在兩種典型的執(zhí)行特征（快查詢與慢查詢）等。

三、 反映運行穩(wěn)定度指標 — 時間方差

方差（Variance） 是衡量數(shù)據(jù)離散程度的統(tǒng)計量，反映數(shù)據(jù)與平均值（均值）的偏離程度。方差越大，數(shù)據(jù)波動越大，分布越分散；方差越小，數(shù)據(jù)越集中，穩(wěn)定性越高。方差的計算公式如下

那么在針對SQL執(zhí)行特征方面，方差可以起到評估SQL執(zhí)行是否穩(wěn)定的作用。低方差，表示執(zhí)行情況平穩(wěn)；高方差則表示執(zhí)行時間波動大，可能存在偶發(fā)性能問題。針對后者一般可考慮檢查索引、索競爭、資源瓶頸等。為了更好地展示對比，這里引入一個概念叫“箱式圖”，是一種用作顯示一組數(shù)據(jù)分散情況資料的統(tǒng)計圖。因形狀如箱子而得名，能顯示出一組數(shù)據(jù)的最大值、最小值、中位數(shù)及上下四分位數(shù)。

下面針對上面兩組執(zhí)行情況，做一個方差分析。這里可以充分利用 DeepSeek 的能力，不需要自己寫程序分析了。

提示詞

針對上面數(shù)據(jù)做方差分析，并將結果通過箱式圖來展示。

從圖中我們可以直觀看到第一組的執(zhí)行情況的時間分布更為集中，而第二組則明顯差異很大，兩者方差差異明顯。這也說明第二組執(zhí)行時出現(xiàn)了明顯的抖動情況。同時上面圖形中也顯示出一些常用的統(tǒng)計指標，包括極數(shù)值（最大值、最小值）、中位數(shù)等。

四、找到語句運行“拐點” — PELT算法

所謂拐點，就是其運行特征前后發(fā)生巨大變化的情況，這通常對應于性能惡化或恢復正常的場景。那么如何在大量SQL運行信息中找到語句運行出現(xiàn)拐點的時刻，對于事后排查分析很重要。這里可以利用 DeepSeek 的能力幫助我們找到這個拐點。我們將這個問題提給 DeepSeek 看它如何反應？

提示詞

針對上面數(shù)據(jù)做拐點分析，并將結果圖形化展示出來。

DeepSeek 思考過程中找到多種識別算法，并最終選擇了PELT算法。因為這種算法有Python包實現(xiàn)，DeepSeek 給出了源碼，稍加修改就可以使用。簡單說明下PELT算法，PELT（Pruned Exact Linear Time）算法是一種高效的變點檢測方法，其核心思想是通過動態(tài)規(guī)劃結合剪枝策略，在保證檢測精度的同時實現(xiàn)線性時間復雜度。該算法以最小化分段成本與懲罰項之和為目標，遞歸地搜索時間序列中的最優(yōu)變點組合。其核心步驟包括：1）初始化動態(tài)規(guī)劃數(shù)組，記錄不同位置的最小累積成本；2）迭代計算每個時間點的最優(yōu)前驅節(jié)點，利用成本函數(shù)（如L2均方誤差或RBF核函數(shù)）評估數(shù)據(jù)分布的突變程度；3）通過剪枝策略剔除不可能成為最優(yōu)解的候選點，顯著減少計算冗余。懲罰項參數(shù)（通?；贐IC準則）動態(tài)平衡檢測靈敏度與過擬合風險，低懲罰值傾向捕捉細微變化，高懲罰值側重顯著突變。該算法尤其適用于金融波動分析、物聯(lián)網設備監(jiān)測等需要實時處理大規(guī)模時序數(shù)據(jù)的場景，在檢測精度與計算效率之間實現(xiàn)了理想平衡。上述內容看起來很拗口，沒關系我們實用看看。針對上面測試數(shù)據(jù)，運用這一算法輸出如下圖形

運用PELT算法，可以找到SQL執(zhí)行出現(xiàn)拐點的情況。如上圖在第一時間點，系統(tǒng)開始出現(xiàn)高延遲查詢的情況，此時的執(zhí)行時長均值從0.051上漲到0.097（上漲90%）；在第二時間點，系統(tǒng)恢復正常，執(zhí)行均值下降了50%。從上面應用可以看出，PELT算法在數(shù)據(jù)庫SQL性能分析中如同一位智能巡檢員，能夠自動識別SQL執(zhí)行過程中的異常波動時刻，幫助管理員快速定位性能瓶頸。其核心作用體現(xiàn)在三個方面：首先，精準捕捉突變時段。通過掃描SQL執(zhí)行時間序列，PELT能智能識別執(zhí)行時長突然飆升的時間節(jié)點（如從0.05秒陡增至0.5秒），這些拐點往往對應著緩存失效、鎖競爭或索引缺失等問題。其次，區(qū)分自然波動與真實異常。相比傳統(tǒng)閾值告警（如固定0.1秒為慢查詢），PELT通過動態(tài)懲罰機制，能過濾日常負載波動（如早晚高峰的規(guī)律性延遲），專注檢測非正常突變（如某時刻因全表掃描導致的持續(xù)性高耗時）。最后，提升根因分析效率。當算法標記出某時間點為異常拐點后，管理員可直接調取該時段的執(zhí)行計劃、資源監(jiān)控日志，快速定位是SQL寫法缺陷（如未使用索引）、硬件瓶頸（如CPU跑滿）還是并發(fā)沖突（如死鎖堆積）所致。

五、找到語句運行“毛刺”— 異常點檢測

毛刺，是指執(zhí)行特征有別于絕大部分正常情況的異常點。這些點對于用戶來說，通常會存在使用體感的明顯變化，如突然變得非?？D等。這些點通常在做事后分析時，會感覺到無從下手，那么看看 DeepSeek 能幫助我們做什么？

提示詞

對上述數(shù)據(jù)做異常點檢測分析，并通過圖形化方式展示結果

通過思考，DeepSeek 使用到異常點檢測通過多維算法融合機制精準捕捉數(shù)據(jù)庫執(zhí)行中的異常行為。其生成的Pytho程序，稍加修改即可使用。程序采用Z-score、滑動窗口統(tǒng)計和孤立森林三重檢測策略：Z-score基于正態(tài)分布假設，計算每個執(zhí)行時長與整體均值的標準差距離（公式：z=σx?μ），能有效識別突破3σ閾值的全局離群點，如某SQL耗時突增至0.141秒（超均值5倍）；滑動窗口法（窗口=5）動態(tài)計算局部均值與標準差（μwin+2σwin），擅長捕捉持續(xù)時間超過10秒的異常窗口，例如緩存失效引發(fā)的連續(xù)性高延遲；孤立森林通過構建隨機二叉樹快速隔離異常路徑，對非高斯分布的隱蔽異常（如0.057秒的早期波動）具有獨特敏感性。三者的邏輯或組合策略共同決定異常點。當然這里存在一點誤差，即初始點被誤標為異常，核心原因在于算法對早期孤立波動的敏感性。具體如下圖所示

通過上圖可以看出，這種機制在真實業(yè)務場景中可有效識別三類典型問題：1）索引失效引發(fā)的全表掃描（表現(xiàn)為單點Z-score異常），2）鎖競爭導致的持續(xù)阻塞（滑動窗口連續(xù)異常），3）內存泄漏引發(fā)的漸進式性能劣化（孤立森林路徑異常）。通過可視化模塊的95%分位線（紫色虛線）與異常熱力圖，DBA 可快速定位出現(xiàn)異常的時間段范圍。

六、物以類聚，有的放矢 — 聚類分析

除了上述針對一條語句的分析外，另外值得關注的是針對全量語句特征的分析。這里可以采用聚類分析的方式，下面是模擬了四種類型的SQL語句，針對執(zhí)行頻次和執(zhí)行時長做了了聚類。這里簡單說明下聚類分析，聚類分析是一種無監(jiān)督機器學習方法，旨在根據(jù)數(shù)據(jù)特征的相似性將樣本劃分為若干組（簇），使同一簇內樣本高度相似，不同簇間差異顯著。在SQL分析場景中，選取執(zhí)行頻次（單位時間執(zhí)行次數(shù)）和平均執(zhí)行時長作為特征，通過標準化處理消除量綱差異后，利用聚類算法將SQL語句劃分為不同執(zhí)行模式類別。下面我們看看執(zhí)行情況

提示詞

上傳的sql1,sql2,sql3,sql4四個文件，表示四條語句在數(shù)據(jù)庫中的執(zhí)行情況。里面的字段分別對應執(zhí)行時間和執(zhí)行時長，請根據(jù)執(zhí)行頻次和執(zhí)行時長兩個維度入手，做SQL語句執(zhí)行特征的聚類分析，并通過圖形化的方式展示出來。

通過上圖可見，我們將SQL精確分類，并做有針對性的優(yōu)化。一類是高頻低耗型（如sql2）：頻繁執(zhí)行但耗時短，需確保其執(zhí)行計劃穩(wěn)定，避免索引失效或資源爭用；一類是低頻高耗型（如sql3、sql4）：執(zhí)行次數(shù)少但單次耗時長，應優(yōu)先優(yōu)化，例如重構查詢邏輯、添加索引或緩存結果；還有一類是過渡型（如sql1）：頻次和時長均居中，需監(jiān)控潛在性能劣化風險。聚類結果直觀展示不同SQL的性能影響權重，指導DBA按“低頻高耗 > 高頻低耗 > 過渡型”順序制定優(yōu)化計劃，最大化投入產出比。聚類分析通過數(shù)據(jù)驅動方式揭示SQL執(zhí)行特征，替代人工經驗分類，提升優(yōu)化效率。但其效果依賴特征選?。ㄈ缭黾臃逯禃r長、資源消耗指標可增強區(qū)分度）和簇數(shù)設定（可通過“肘部法則”選擇最佳K值）。此外，需結合業(yè)務場景解讀結果，避免單純依賴數(shù)學劃分忽略實際語義。例如，高耗時的低頻SQL可能是關鍵報表查詢，需保障其穩(wěn)定性而非盲目削減耗時。綜上，聚類分析為SQL優(yōu)化提供了科學的分類框架，輔助DBA從海量日志中快速定位重點問題，是實現(xiàn)數(shù)據(jù)庫智能調優(yōu)的手段之一。