慢 SQL 這件事，很多團(tuán)隊(duì)最先出的問題不是不會(huì)查，而是很多團(tuán)隊(duì)未將其作為一條持續(xù)工作來負(fù)責(zé)。

收到告警后，DBA 先看；SQL 要改，后端接手；實(shí)例波動(dòng)，SRE 去對監(jiān)控；問題過去以后，大家又回到各自的工作里。結(jié)果就是同一類慢 SQL 多次出現(xiàn)，團(tuán)隊(duì)每次都從 slow log、EXPLAIN 和群消息重新排查。

NineData 社區(qū)版適合放在這條鏈路里。

本文只討論在 MySQL 慢 SQL 場景下的使用邊界。NineData 社區(qū)版支持離線部署、Docker 單機(jī)部署，數(shù)據(jù)庫 DevOps 提供 10 個(gè)數(shù)據(jù)源可用額度，核心功能與專業(yè)版保持一致。如果團(tuán)隊(duì)要的是分布式集群、跨區(qū)域?yàn)?zāi)備、靈活擴(kuò)展和 SLA，那屬于企業(yè)版范圍，這里不展開。

問題不在于“誰都能不能看慢 SQL”，而在于：誰應(yīng)該主動(dòng)用，誰應(yīng)該協(xié)同用，誰應(yīng)該通過它判斷團(tuán)隊(duì)最近是不是還在重復(fù)出現(xiàn)問題。

更適合主動(dòng)用的人，通常還是 DBA

如果只選一個(gè)主角色，通常還是 DBA。

原因很簡單。

慢 SQL 更需要先做的，不是把一條 SQL 截圖發(fā)出來，而是先判斷：

? 最近哪類慢查詢在變多

? 哪些 SQL 模板值得優(yōu)先處理

? 是索引問題、寫法問題，還是執(zhí)行代價(jià)已經(jīng)被排序、回表、參數(shù)范圍放大了

? 哪些結(jié)論應(yīng)該進(jìn)入 SQL 規(guī)范、審批和后續(xù)變更流程

NineData 慢查詢分析支持按時(shí)間范圍看趨勢

按 SQL 模板聚合，再下鉆到具體 SQL 樣本，

還可以按 Template、Database、Host、User 過濾，

并查看性能診斷、規(guī)則檢查、索引建議。這套能力更適配先由 DBA 用起來，因?yàn)?DBA 更需要先把“哪些問題值得管、為什么要先管”這件事判斷清楚。

所以對 MySQL 慢 SQL 來說，DBA 更像是方法和優(yōu)先級的負(fù)責(zé)人。

不是因?yàn)槁?SQL 僅可由 DBA 查看，而是因?yàn)槿绻麤]有 DBA 先把模板、風(fēng)險(xiǎn)和處理順序理出來，團(tuán)隊(duì)很容易只剩下臨時(shí)應(yīng)對。

第二個(gè)更適合直接用的人，是負(fù)責(zé)核心鏈路的后端

慢 SQL 最終不會(huì)停在數(shù)據(jù)庫里，它一定會(huì)回到代碼里。

很多團(tuán)隊(duì)的慢 SQL 之所以長期難以持續(xù)優(yōu)化，不是 DBA 沒分析出來，而是結(jié)論到了研發(fā)側(cè)以后，被簡化成“加個(gè)索引”或者“把 SQL 改一下”。這樣改出來的結(jié)果通常不穩(wěn)定，因?yàn)楹蠖俗约翰]有充分理解：

? 這類慢 SQL 對應(yīng)的是哪條查詢路徑

? 為什么同一個(gè)模板會(huì)多次出現(xiàn)

? 是篩選條件、分頁方式、排序規(guī)則，還是返回列把成本拉高了

? 改動(dòng)以后預(yù)期改善的到底是什么

NineData 社區(qū)版在這里的價(jià)值，不只是慢查詢分析，還有后面的 SQL 窗口。

DBA 找到問題模板以后，后端可以繼續(xù)回 SQL 窗口做 EXPLAIN、驗(yàn)證改寫方案，確認(rèn)是不是要調(diào)整 SQL 寫法、索引設(shè)計(jì)或者查詢路徑。

這里還有一個(gè)容易被忽視的安全收益： 通過 NineData 的 SQL 窗口查看慢 SQL 和執(zhí)行 EXPLAIN，可以讓后端同學(xué)不再需要把生產(chǎn)庫的賬號(hào)配置在 Navicat、 Sequel Ace 或 IDEA 插件等本地客戶端里。在本地化、內(nèi)網(wǎng)部署的環(huán)境下，這意味著各類對慢 SQL 的診斷操作都集中在可追溯的平臺(tái)內(nèi)，減少了因本地工具和配置錯(cuò)誤帶來的安全風(fēng)險(xiǎn)。這對后端來說，是額外的安全保障，也是推動(dòng)研發(fā)流程規(guī)范化的一個(gè)有效起點(diǎn)。

所以對后端來說，NineData 更適配的用法不是“偶爾看一眼報(bào)表”，而是把它當(dāng)成一條從慢 SQL 模板回到具體 SQL 驗(yàn)證的入口，同時(shí)也是一個(gè)更安全的診斷環(huán)境。

如果 DBA 是把問題找出來的人，后端就是把問題切實(shí)落地到代碼的人。

SRE 不一定天天盯慢 SQL 明細(xì)，但需要參與判斷時(shí)點(diǎn)和環(huán)境

SRE 在這條鏈路里的位置，和 DBA、后端不一樣。

SRE 未必需要每天都專注于慢查詢詳情，也不一定直接改 SQL。

但只要團(tuán)隊(duì)已經(jīng)進(jìn)入“慢 SQL 影響線上穩(wěn)定性”的階段，SRE 通常需要參與。

因?yàn)楹芏嗦?SQL 的表現(xiàn)，和時(shí)點(diǎn)、流量、資源、發(fā)布窗口、實(shí)例狀態(tài)都有關(guān)系。

同一個(gè)模板，平峰可能還好，高峰時(shí)就慢；某次上線后才開始出現(xiàn)；某段時(shí)間連接數(shù)、IO 或并發(fā)行為變化以后，問題被明顯放大。

這類判斷如果離開了 SRE，團(tuán)隊(duì)很容易把全部問題都?xì)w因到 SQL 本身，最后把環(huán)境因素忽略。

所以 SRE 更適合怎么用 NineData 社區(qū)版？

不是每天去篩選執(zhí)行耗時(shí)較長的 SQL，而是結(jié)合監(jiān)控、告警和變更記錄，看慢查詢趨勢是不是在某個(gè)時(shí)間點(diǎn)開始上升，再和 DBA 一起判斷：

? 這是查詢寫法本身的問題

? 還是某次環(huán)境變化把問題放大了

? 是偶發(fā)尖峰，還是某類模板已經(jīng)開始持續(xù)升溫

SRE 在這里更像“把慢 SQL 結(jié)合實(shí)際運(yùn)行環(huán)境分析”的那個(gè)人。

技術(shù)負(fù)責(zé)人更適合關(guān)注的，不是單條 SQL，而是團(tuán)隊(duì)最近是不是還在重復(fù)出現(xiàn)同類問題

技術(shù)負(fù)責(zé)人一般不會(huì)去逐條看 EXPLAIN

他更應(yīng)該關(guān)心的，是慢 SQL 這件事到底有沒有從“出現(xiàn)問題后再排查”變成“平時(shí)能看、能改、能復(fù)盤”。

從這個(gè)角度看，技術(shù)負(fù)責(zé)人更值得關(guān)注的通常不是單條語句，而是：

? 最近 7 天或 30 天，哪些 SQL 模板多次出現(xiàn)

? 哪些問題已經(jīng)被治理下來了，哪些還在多次出現(xiàn)

? 是不是總在同一類查詢路徑上重復(fù)出問題

? 有沒有必要把某類風(fēng)險(xiǎn)前移到 SQL 規(guī)范、審批或開發(fā)階段

此外，還有一層業(yè)務(wù)視角值得留意： 影響登錄、下單這類核心業(yè)務(wù)的慢 SQL，哪怕只出現(xiàn)幾次，優(yōu)先級也高于那些執(zhí)行次數(shù)多但影響較大的報(bào)表查詢。技術(shù)負(fù)責(zé)人不一定自己去看慢 SQL 明細(xì)，但需要確保團(tuán)隊(duì)在定優(yōu)先級時(shí)，把“業(yè)務(wù)重要性”放進(jìn)判斷標(biāo)準(zhǔn)里。

NineData 的慢查詢趨勢、SQL 模板聚合和診斷建議，對技術(shù)負(fù)責(zé)人的核心價(jià)值也在這里。

不是替他做技術(shù)判斷，而是讓他看到團(tuán)隊(duì)最近是在解決問題，還是在重復(fù)同一類問題。

對負(fù)責(zé)人來說，這類工具更實(shí)用的時(shí)候，不是能看見一條 SQL 多慢，而是能看見團(tuán)隊(duì)的數(shù)據(jù)庫問題是不是還在重復(fù)出現(xiàn)。

實(shí)際該怎么分工

如果把 MySQL 慢 SQL 這件事拆開看，角色分工通常會(huì)比較清楚：

? DBA： 主用戶。負(fù)責(zé)看趨勢、看模板、定優(yōu)先級、給出判斷方向。

? 后端： 直接協(xié)作者。負(fù)責(zé)把問題落實(shí)到代碼、SQL 寫法和查詢路徑，同時(shí)獲得一個(gè)更安全的診斷環(huán)境。

? SRE： 環(huán)境視角的協(xié)作者。負(fù)責(zé)把慢查詢和監(jiān)控、時(shí)點(diǎn)、實(shí)例狀態(tài)放在一起看。

? 技術(shù)負(fù)責(zé)人： 結(jié)果和趨勢的使用者。負(fù)責(zé)看重復(fù)問題、治理節(jié)奏、規(guī)則前移，以及確保業(yè)務(wù)優(yōu)先級被納入考量。

這四個(gè)角色不需要每天都用同樣深度去看慢 SQL。

更需要日常主動(dòng)用起來的，通常還是 DBA 和負(fù)責(zé)核心鏈路的后端。

SRE 和技術(shù)負(fù)責(zé)人更適合在關(guān)鍵時(shí)點(diǎn)、關(guān)鍵趨勢和關(guān)鍵復(fù)盤上參與。

為什么 NineData 社區(qū)版適合放在這種協(xié)作里

NineData 社區(qū)版的優(yōu)勢，不在于把慢 SQL 變成某一個(gè)人的個(gè)人工具，而在于它把幾段原本分散的動(dòng)作收進(jìn)了一套本地化工作臺(tái)里。

這條鏈路至少包括：

? 慢查詢分析： 看趨勢、看模板、看樣本、看診斷建議

? SQL 窗口： 繼續(xù)做 EXPLAIN 和改寫驗(yàn)證，同時(shí)避免本地工具直連生產(chǎn)庫

? SQL 任務(wù)： 進(jìn)入提交、審批、執(zhí)行、回滾流程

這意味著團(tuán)隊(duì)里不同角色雖然看問題的角度不同，但不必再靠 slow log 截圖、客戶端截圖和口頭同步來拼接事實(shí)。

DBA 先把高頻模板找出來，后端繼續(xù)驗(yàn)證和改 SQL，SRE 結(jié)合環(huán)境時(shí)點(diǎn)輔助判斷，技術(shù)負(fù)責(zé)人再從趨勢上看治理結(jié)果——這條鏈路才更容易跑順。

對有本地化、內(nèi)網(wǎng)、離線部署需求的團(tuán)隊(duì)，這一點(diǎn)會(huì)更實(shí)際。

因?yàn)楣ぞ卟恢皇悄苡?，還得能被團(tuán)隊(duì)持續(xù)用下去。

總結(jié)

MySQL 慢 SQL 不只是 DBA 的問題，也不適合被分配給各類角色。

如果一定要問“誰更適合用”，答案通常是：

? 更適合主動(dòng)用的人，是 DBA

? 更適合一起把問題落下去的人，是后端

? 更適合協(xié)助團(tuán)隊(duì)判斷時(shí)點(diǎn)和環(huán)境的人，是 SRE

? 更適合關(guān)注治理有沒有形成結(jié)果、業(yè)務(wù)有沒有受影響的人，是技術(shù)負(fù)責(zé)人

慢 SQL 更關(guān)鍵的是，不是理解執(zhí)行計(jì)劃，而是讓不同角色圍繞同一類問題持續(xù)協(xié)作。

在這一點(diǎn)上，NineData 社區(qū)版更適合被放在團(tuán)隊(duì)慢 SQL 治理的主鏈路里，而不是只當(dāng)成一個(gè)問題發(fā)生后才啟用的工具。

審核編輯 黃宇