周五下午三點(diǎn)某數(shù)據(jù)平臺(tái)的運(yùn)維群里開(kāi)始有人喊系統(tǒng)卡了。我登錄 SAP HANA 看了一眼CPU 已經(jīng)沖到 85%可昂貴的語(yǔ)句追蹤里一條慢 SQL 都沒(méi)有——單條執(zhí)行都低于 1 秒。這個(gè)場(chǎng)景在 SAP HANA 的故障排查里太典型了真正拖垮系統(tǒng)的往往不是那幾條明顯的慢 SQL而是大量高頻短查詢的累積。要抓住它們得打開(kāi) Capture Request Statistics要讀懂它們?yōu)槭裁绰值冒褕?zhí)行計(jì)劃導(dǎo)成 PLV 文件用 VS Code 打開(kāi)逐節(jié)點(diǎn)分析。這篇文章就把這套完整流程寫(xiě)下來(lái)。1. 為什么默認(rèn)的昂貴語(yǔ)句追蹤抓不住隱形慢 SQL1.1 昂貴語(yǔ)句追蹤的 1 秒閾值陷阱SAP HANA 默認(rèn)并不是什么都不記錄它有一套叫 Expensive Statement Trace 的機(jī)制。這套機(jī)制看名字就知道專(zhuān)門(mén)記錄執(zhí)行得比較貴的語(yǔ)句。問(wèn)題是它有一個(gè)硬性的執(zhí)行時(shí)間閾值在indexserver.ini配置文件的[expensive_statement]段里參數(shù)叫threshold_execution_time默認(rèn)值是 1000000 微秒也就是 1 秒。這意味著什么只有單次執(zhí)行時(shí)間超過(guò) 1 秒的 SQL 才會(huì)被記錄到昂貴語(yǔ)句日志里。很多運(yùn)維同學(xué)排查慢 SQL 時(shí)習(xí)慣先看這個(gè)日志結(jié)果發(fā)現(xiàn)里面空空如也于是得出數(shù)據(jù)庫(kù)沒(méi)有慢 SQL的結(jié)論。但線上業(yè)務(wù)的真實(shí)情況往往是單次 100 毫秒的查詢每秒被調(diào) 500 次一分鐘累計(jì)占用數(shù)據(jù)庫(kù) CPU 的時(shí)間就是 300 秒。單拿出來(lái)哪一條都不夠昂貴標(biāo)準(zhǔn)合在一起卻能把整個(gè)實(shí)例拖垮。這就引出一個(gè)非常關(guān)鍵的觀點(diǎn)慢 SQL 的定義不能只看單次耗時(shí)還要看執(zhí)行頻率和累計(jì)資源消耗。昂貴語(yǔ)句追蹤本質(zhì)上是一個(gè)事后告警工具適合人工抽查不適合做全量畫(huà)像。想看清系統(tǒng)里到底跑了什么需要的是另一套能力——全量請(qǐng)求捕獲。1.2 高頻短查詢?nèi)绾温峡逑到y(tǒng)高頻短查詢的最可怕之處不是每一次執(zhí)行有多重而是它的累積效應(yīng)。舉個(gè)例子一個(gè)查詢單次 50 毫秒執(zhí)行 2000 次總耗時(shí)是 100 秒。這 100 秒里包含了對(duì) CPU 的占用、內(nèi)存的申請(qǐng)釋放、計(jì)劃緩存的查找和更新、結(jié)果集的序列化。如果并發(fā)高還會(huì)放大鎖等待和線程排隊(duì)。更隱蔽的是大量短查詢會(huì)不斷沖擊執(zhí)行計(jì)劃緩存導(dǎo)致真正需要復(fù)用的好計(jì)劃被頻繁換出整體命中率下降讓每條 SQL 的平均編譯開(kāi)銷(xiāo)上升。用戶體感就是系統(tǒng)整體變卡但抓單條 SQL 又抓不到。這類(lèi)問(wèn)題在接口型業(yè)務(wù)里最常見(jiàn)。前端輪詢接口、定時(shí)任務(wù)高頻掃描、報(bào)表工具反復(fù)拉取同一段數(shù)據(jù)都會(huì)產(chǎn)生這種隱形慢 SQL。它們不會(huì)寫(xiě)進(jìn)昂貴語(yǔ)句日志也不會(huì)觸發(fā)告警只會(huì)讓 CPU 慢慢爬升直到某一天高峰期扛不住。1.3 什么場(chǎng)景值得開(kāi)捕獲Capture Request Statistics 的核心價(jià)值在于它把所有經(jīng)過(guò) SQL 引擎的請(qǐng)求都記錄下來(lái)無(wú)論快慢。這樣你拿到的不是幾個(gè)典型樣本而是一段時(shí)間內(nèi)的完整請(qǐng)求畫(huà)像。我一般在三類(lèi)場(chǎng)景下會(huì)主動(dòng)開(kāi)啟捕獲。第一類(lèi)是定期的性能巡檢不需要等出故障先抓一到兩天的全量數(shù)據(jù)做基線第二類(lèi)是系統(tǒng)上線前后的對(duì)比確認(rèn)新功能或新版本有沒(méi)有引入異常的查詢模式第三類(lèi)是說(shuō)不清哪里慢的疑難雜癥沒(méi)有明確慢 SQL但整體 CPU 或響應(yīng)時(shí)間異常這時(shí)候必須靠全量數(shù)據(jù)還原現(xiàn)場(chǎng)。2. 打開(kāi) Capture Request Statistics參數(shù)、落表和性能代價(jià)2.1 三步開(kāi)關(guān)命令、驗(yàn)證與生效范圍打開(kāi) Capture Request Statistics 的操作非常輕量一條 ALTER SYSTEM 語(yǔ)句就能完成。在目標(biāo)租戶庫(kù)執(zhí)行ALTER SYSTEM ALTER CONFIGURATION (indexserver.ini, SYSTEM) SET (sql, capture_request_statistics) true WITH RECONFIGURE;注意幾個(gè)細(xì)節(jié)。第一SYSTEM表示在集群級(jí)別修改配置這個(gè)配置會(huì)廣播到所有 indexserver 節(jié)點(diǎn)在有多節(jié)點(diǎn)、多租戶的架構(gòu)下不需要逐臺(tái)登錄設(shè)置。第二WITH RECONFIGURE必不可少它讓配置立即生效否則只是寫(xiě)入了配置文件要等實(shí)例重啟才生效。第三這個(gè)參數(shù)作用在 indexserver 進(jìn)程上所以要在目標(biāo)租戶庫(kù)執(zhí)行而不是在 SYSTEMDB 里執(zhí)行了事。設(shè)置完成后先確認(rèn)一下生效狀態(tài)SELECT FILE_NAME, SECTION, KEY, VALUE FROM SYS.M_CONFIG WHERE FILE_NAME indexserver.ini AND KEY capture_request_statistics;看到 VALUE 為 true就說(shuō)明開(kāi)關(guān)已經(jīng)生效。此時(shí)系統(tǒng)里的請(qǐng)求會(huì)開(kāi)始往統(tǒng)計(jì)表寫(xiě)入數(shù)據(jù)。2.2 捕獲數(shù)據(jù)落在哪兩張統(tǒng)計(jì)表的關(guān)鍵字段開(kāi)啟捕獲后數(shù)據(jù)落在_SYS_STATISTICS模式下的兩張核心表里。一張是REQUESTS_CAPTURED記錄每一次請(qǐng)求的執(zhí)行概況另一張是STATEMENTS_CAPTURED保存 SQL 語(yǔ)句文本。兩者通過(guò)STATEMENT_KEY字段關(guān)聯(lián)。REQUESTS_CAPTURED里我最常用到的字段有這些字段含義用途START_TIME請(qǐng)求開(kāi)始時(shí)間做時(shí)間段過(guò)濾圈定業(yè)務(wù)高峰期DURATION_MICROSEC請(qǐng)求總耗時(shí)微秒計(jì)算平均耗時(shí)、總耗時(shí)STATEMENT_HASHSQL 文本哈希把相同文本的 SQL 聚合成一類(lèi)STATEMENT_KEY語(yǔ)句唯一鍵關(guān)聯(lián)到 STATEMENTS_CAPTUREDUSER_NAME執(zhí)行用戶過(guò)濾系統(tǒng)請(qǐng)求、定向分析業(yè)務(wù)用戶APPLICATION_NAME應(yīng)用名稱(chēng)定位到具體接口或客戶端TOTAL_CPU_TIME請(qǐng)求消耗的 CPU 時(shí)間看資源消耗比耗時(shí)更直觀這張表是典型的寬表字段很多。實(shí)際做分析時(shí)先抓住執(zhí)行次數(shù)、總耗時(shí)、平均耗時(shí)、CPU 時(shí)間這四類(lèi)就足夠邁出第一步了。2.3 捕獲的代價(jià)采樣與窗口期建議先說(shuō)結(jié)論Capture Request Statistics 有額外開(kāi)銷(xiāo)但通?？煽亍Ｃ看握?qǐng)求結(jié)束后數(shù)據(jù)庫(kù)需要把統(tǒng)計(jì)信息寫(xiě)入統(tǒng)計(jì)表這個(gè)動(dòng)作本身會(huì)消耗一定 CPU 和 IO。特別是在每秒幾千次短查詢的高并發(fā)場(chǎng)景寫(xiě)入放大效應(yīng)會(huì)比較明顯。所以我不建議把這個(gè)開(kāi)關(guān)常年常開(kāi)更推薦窗口期狩獵的做法。比如設(shè)定 30 分鐘到 2 小時(shí)的捕獲窗口覆蓋業(yè)務(wù)高峰或者做 1 到 2 天的全量捕獲用于季度巡檢。捕獲結(jié)束后立刻關(guān)閉。如果確實(shí)需要長(zhǎng)期監(jiān)控可以研究一下采樣相關(guān)參數(shù)把捕獲比例調(diào)低但那樣會(huì)損失全量數(shù)據(jù)的完整性屬于權(quán)衡方案。我的經(jīng)驗(yàn)是排查性能問(wèn)題不需要 7x24 小時(shí)全量捕獲抓一個(gè)完整的業(yè)務(wù)周期比如一個(gè)工作日下午加一個(gè)早晨高峰已經(jīng)能覆蓋大多數(shù)典型問(wèn)題。3. 從統(tǒng)計(jì)表里撈出真正值得優(yōu)化的 Top SQL3.1 第一刀按 SQL 指紋做總耗時(shí)聚合數(shù)據(jù)抓下來(lái)了直接一條條看肯定不現(xiàn)實(shí)。第一步一定是聚合。按什么維度聚合我建議按STATEMENT_HASH做分組這個(gè)字段相當(dāng)于 SQL 的指紋不同文本但結(jié)構(gòu)相似的語(yǔ)句會(huì)落在不同的哈希上歸并起來(lái)非常干凈。下面這條查詢是整個(gè)過(guò)程的核心建議直接收藏SELECT RC.STATEMENT_HASH, COUNT(*) AS EXECUTION_COUNT, SUM(RC.DURATION_MICROSEC) / 1000000 AS TOTAL_DURATION_SEC, AVG(RC.DURATION_MICROSEC) / 1000 AS AVG_DURATION_MS, MAX(RC.DURATION_MICROSEC) / 1000 AS MAX_DURATION_MS, SUM(RC.TOTAL_CPU_TIME) / 1000000 AS TOTAL_CPU_SEC FROM _SYS_STATISTICS.REQUESTS_CAPTURED RC WHERE RC.START_TIME ADD_SECONDS(CURRENT_UTCTIMESTAMP, -3600) GROUP BY RC.STATEMENT_HASH ORDER BY TOTAL_DURATION_SEC DESC LIMIT 20;為什么排序用 SUM 而不是 MAX這是很多初學(xué)者容易犯的錯(cuò)。MAX只能告訴你最極端的那一次有多慢如果把所有資源都用來(lái)優(yōu)化這一條很可能是在大海撈針而SUM把執(zhí)行次數(shù)和單次耗時(shí)做了乘法直接量化了這條 SQL 在這段時(shí)間內(nèi)總共消耗了多少數(shù)據(jù)庫(kù)時(shí)間。優(yōu)化掉的每一秒都是實(shí)打?qū)嵉南到y(tǒng)吞吐量提升。3.2 第二刀關(guān)聯(lián)出 SQL 文本拿到哈希排名后下一步是把 SQL 文本撈出來(lái)。哈希只是一個(gè)代號(hào)你不知道具體是哪個(gè)查詢。通過(guò)STATEMENT_KEY關(guān)聯(lián)到STATEMENTS_CAPTURED表就能看到完整的語(yǔ)句內(nèi)容SELECT SC.STATEMENT_STRING, RC.STATEMENT_HASH, COUNT(*) AS EXECUTION_COUNT, SUM(RC.DURATION_MICROSEC) / 1000000 AS TOTAL_DURATION_SEC FROM _SYS_STATISTICS.REQUESTS_CAPTURED RC JOIN _SYS_STATISTICS.STATEMENTS_CAPTURED SC ON RC.STATEMENT_KEY SC.STATEMENT_KEY WHERE RC.START_TIME ADD_SECONDS(CURRENT_UTCTIMESTAMP, -3600) GROUP BY RC.STATEMENT_HASH, SC.STATEMENT_STRING ORDER BY TOTAL_DURATION_SEC DESC LIMIT 20;執(zhí)行這條查詢時(shí)我建議多等幾秒因?yàn)榫酆系臄?shù)據(jù)量可能很大。如果同時(shí)抓了多個(gè)節(jié)點(diǎn)的數(shù)據(jù)最終統(tǒng)計(jì)表里是整合后的結(jié)果不需要手動(dòng)合并。拿到 SQL 文本后先肉眼掃一遍 WHERE 條件、JOIN 條件、子查詢結(jié)構(gòu)很多問(wèn)題在這一步已經(jīng)能猜個(gè)七八分。真正的確認(rèn)還得靠執(zhí)行計(jì)劃。3.3 快速通道用 M_EXECUTION_STATISTICS 應(yīng)急看最近請(qǐng)求有一種情況不需要開(kāi) Capture Request Statistics你只想看看最近幾分鐘系統(tǒng)在跑什么比如正在處理一個(gè)實(shí)時(shí)故障。這時(shí)候可以查詢系統(tǒng)視圖SYS.M_EXECUTION_STATISTICS它記錄了最近實(shí)際執(zhí)行過(guò)的請(qǐng)求而且直接帶有STATEMENT_STRING字段連關(guān)聯(lián)都省了。SELECT STATEMENT_STRING, COUNT(*) AS EXECUTION_COUNT, SUM(DURATION_MICROSEC) / 1000000 AS TOTAL_DURATION_SEC, AVG(DURATION_MICROSEC) / 1000 AS AVG_DURATION_MS FROM SYS.M_EXECUTION_STATISTICS WHERE START_TIME ADD_SECONDS(CURRENT_UTCTIMESTAMP, -900) GROUP BY STATEMENT_STRING ORDER BY TOTAL_DURATION_SEC DESC LIMIT 10;但要提醒一句這個(gè)視圖是個(gè)內(nèi)存環(huán)只保留最近一段時(shí)間或最近一部分請(qǐng)求容量有限不適合做歷史分析和完整畫(huà)像。它的定位是應(yīng)急快照用于快速確認(rèn)現(xiàn)在到底在跑什么。真正要寫(xiě)分析報(bào)告、做趨勢(shì)對(duì)比還是得靠 Capture Request Statistics 落表的數(shù)據(jù)。3.4 順手做體檢執(zhí)行次數(shù)、平均耗時(shí)、CPU 占比除了總耗時(shí)排名我通常還會(huì)順手分析三個(gè)維度因?yàn)樗鼈兡芊从巢煌?lèi)型的性能問(wèn)題。執(zhí)行次數(shù)特別高但平均耗時(shí)很低的 SQL往往是接口輪詢或者循環(huán)調(diào)用優(yōu)化思路是緩存結(jié)果、減少調(diào)用次數(shù)或者改批量查詢平均耗時(shí)高但執(zhí)行次數(shù)低的 SQL一般是復(fù)雜報(bào)表或大范圍掃描優(yōu)化思路是加過(guò)濾條件、拆分查詢、優(yōu)化 JOIN 順序CPU 時(shí)間占比異常高的 SQL即使耗時(shí)不高也可能是大量運(yùn)算、函數(shù)處理或類(lèi)型轉(zhuǎn)換導(dǎo)致的這類(lèi)問(wèn)題會(huì)在 CPU 掛高時(shí)特別明顯。這三個(gè)維度的分析不需要額外查詢上面的聚合 SQL 已經(jīng)包含了相關(guān)字段只需要改變排序和觀察角度。4. 把執(zhí)行計(jì)劃導(dǎo)出 .plv用 VS Code 打開(kāi)4.1 統(tǒng)計(jì)回答是誰(shuí)執(zhí)行計(jì)劃回答為什么前面做的所有工作都是在回答一個(gè)問(wèn)題系統(tǒng)里哪些 SQL 消耗最大。這是一個(gè)定位的過(guò)程。但要真正解決問(wèn)題必須回答下一個(gè)問(wèn)題這些 SQL 為什么慢是表掃描走了全表是 JOIN 順序有問(wèn)題還是 WHERE 條件里的函數(shù)導(dǎo)致索引失效回答為什么靠執(zhí)行計(jì)劃。SAP HANA 的執(zhí)行計(jì)劃可視化文件就是 PLV全稱(chēng) Plan Visualization。它把優(yōu)化器生成的算子樹(shù)轉(zhuǎn)換成圖形界面每個(gè)節(jié)點(diǎn)展示算子類(lèi)型、消耗時(shí)間、處理行數(shù)、具體屬性。對(duì)于熟悉節(jié)點(diǎn)閱讀的人來(lái)說(shuō)一張 PLV 比幾千行日志都直觀。4.2 產(chǎn)出一條 .plv 的兩種常見(jiàn)方法第一條路徑是在 SQL 控制臺(tái)里用EXPLAIN PLAN語(yǔ)句直接生成執(zhí)行計(jì)劃。比如EXPLAIN PLAN FOR SELECT ORDER_ID, CUSTOMER_NAME, TOTAL_AMOUNT FROM ORDER_HEADER WHERE ORDER_DATE 2024-01-01 AND ORDER_DATE 2024-02-01;執(zhí)行后控制臺(tái)會(huì)返回一個(gè)結(jié)果集里面按層級(jí)列出了算子樹(shù)。在 SAP HANA 的 Database Explorer 里可以在這個(gè)結(jié)果面板上找到導(dǎo)出計(jì)劃或Visualize Plan之類(lèi)的按鈕把計(jì)劃保存成.plv文件。第二條路徑更直接在 Database Explorer 里打開(kāi)某條 SQL 語(yǔ)句的執(zhí)行歷史找到具體某一次執(zhí)行直接下載對(duì)應(yīng)的執(zhí)行計(jì)劃文件。這種方式拿到的通常是那份實(shí)際執(zhí)行過(guò)的計(jì)劃包含真實(shí)行數(shù)和耗時(shí)比純估算計(jì)劃更有診斷價(jià)值。需要特別注意一個(gè)坑EXPLAIN PLAN FOR生成的是優(yōu)化器估算的計(jì)劃反映的是數(shù)據(jù)庫(kù)認(rèn)為應(yīng)該怎么執(zhí)行而不是實(shí)際上怎么執(zhí)行。在統(tǒng)計(jì)信息不準(zhǔn)確或查詢過(guò)于復(fù)雜時(shí)估算計(jì)劃和實(shí)際計(jì)劃可能差別很大。定位問(wèn)題時(shí)優(yōu)先使用實(shí)際執(zhí)行計(jì)劃。4.3 VS Code 環(huán)境與擴(kuò)展配置拿到 .plv 文件后用文本編輯器打開(kāi)只能看到一堆 JSON真正舒服的打開(kāi)方式是使用可視化渲染工具。VS Code 里可以直接做到這一點(diǎn)。先在擴(kuò)展市場(chǎng)搜索并安裝 SAP 官方提供的 SAP HANA Database Explorer 擴(kuò)展。安裝完成后VS Code 會(huì)把.plv文件關(guān)聯(lián)到該擴(kuò)展的執(zhí)行計(jì)劃可視化視圖。直接點(diǎn)擊文件名打開(kāi)就能看到圖形化的算子樹(shù)。如果擴(kuò)展裝好了雙擊還是顯示 JSON不需要卸載重裝右鍵點(diǎn)擊文件選擇 Open With然后手動(dòng)選擇 SAP HANA 相關(guān)的執(zhí)行計(jì)劃查看器即可。這種手動(dòng)關(guān)聯(lián)在第一次使用時(shí)很常見(jiàn)。4.4 打開(kāi)失敗和渲染異常的排查邏輯沒(méi)有擴(kuò)展時(shí)的表現(xiàn)最直接文件會(huì)以純文本 JSON 打開(kāi)一眼就能識(shí)別。有擴(kuò)展但打不開(kāi)可分為三種情況。第一文件后綴不是.plv可能是.json或.txt需要右鍵手動(dòng)關(guān)聯(lián)第二文件內(nèi)容不完整比如從控制臺(tái)復(fù)制時(shí)只復(fù)制了一部分 JSON這種情況需要重新導(dǎo)出完整文件第三版本兼容性問(wèn)題數(shù)據(jù)庫(kù)版本和 VS Code 擴(kuò)展版本跨度太大時(shí)某些節(jié)點(diǎn)屬性可能顯示不全但通常不會(huì)完全打不開(kāi)。一個(gè)比較實(shí)用的兜底方案如果 VS Code 的環(huán)境一直配置不好可以把 .plv 文件直接拖入 SAP HANA Database Explorer 的網(wǎng)頁(yè)版網(wǎng)頁(yè)版同樣內(nèi)置了 PlanViz 渲染器功能不輸 VS Code。5. 讀懂一張 PLV五個(gè)必須看的抓手5.1 先看算子樹(shù)從根到葉子的閱讀順序打開(kāi)一張 PLV第一眼看到的是縱向或橫向的算子樹(shù)。根節(jié)點(diǎn)在最上端或最左端葉子節(jié)點(diǎn)在底部或最右端數(shù)據(jù)從葉子往根方向流動(dòng)。每一層節(jié)點(diǎn)都代表一個(gè)具體的操作全表掃描、索引查找、JOIN、聚合、排序、投影等等。我最先看的是根節(jié)點(diǎn)?？偤臅r(shí)就放在那里它旁邊的耗時(shí)條通常很夸張。如果根節(jié)點(diǎn)顯示 85% 的耗時(shí)都來(lái)自底下某個(gè)子樹(shù)那問(wèn)題就不需要繼續(xù)猜了——所有注意力都應(yīng)該投到那個(gè)子樹(shù)里去。這個(gè)閱讀順序看起來(lái)簡(jiǎn)單但很多人在 PLV 里迷路的唯一原因就是從葉子開(kāi)始看結(jié)果被一堆細(xì)枝末節(jié)的操作帶偏。正確做法永遠(yuǎn)是先看根再看最耗時(shí)的分支最后才收縮到具體算子。5.2 行數(shù)估算值和實(shí)際值相差一個(gè)數(shù)量級(jí)就要警惕PLV 里每個(gè)節(jié)點(diǎn)都標(biāo)注了行數(shù)。這可能是整張計(jì)劃里最有價(jià)值的數(shù)據(jù)?？吹臅r(shí)候要區(qū)分兩種行數(shù)估算行數(shù)Estimated Rows和實(shí)際行數(shù)Actual Rows。估算行數(shù)是優(yōu)化器基于統(tǒng)計(jì)信息推算出來(lái)的實(shí)際行數(shù)是查詢真正處理的數(shù)據(jù)量。當(dāng)兩者非常接近時(shí)說(shuō)明優(yōu)化器的判斷靠譜執(zhí)行計(jì)劃整體可信當(dāng)兩者相差超過(guò)一個(gè)數(shù)量級(jí)時(shí)說(shuō)明統(tǒng)計(jì)信息已經(jīng)過(guò)期、直方圖不準(zhǔn)確或者存在復(fù)雜表達(dá)式讓優(yōu)化器無(wú)法準(zhǔn)確估算。這種偏差是性能問(wèn)題的溫床可能直接導(dǎo)致優(yōu)化器選擇了錯(cuò)誤的 JOIN 順序或掃描方式。在實(shí)際計(jì)劃里發(fā)現(xiàn)這類(lèi)偏差下一步就是刷新相關(guān)表的統(tǒng)計(jì)信息比如執(zhí)行ANALYZE相關(guān)操作然后再對(duì)比新計(jì)劃。很多莫名其妙慢的查詢刷新統(tǒng)計(jì)信息后自動(dòng)就好了。5.3 三類(lèi)重點(diǎn)算子掃描、Join、聚合算子種類(lèi)很多但性能診斷中需要聚焦的其實(shí)只有三類(lèi)。第一類(lèi)是 TABLE SCAN?？吹揭粋€(gè)大的 TABLE SCAN 節(jié)點(diǎn)時(shí)要立刻確認(rèn)表是列存還是行存過(guò)濾條件下推到了哪一層以及有沒(méi)有做分區(qū)裁剪。最壞的情況是整張幾億行的列存表從頭掃到尾那基本等于把查詢速度的下限拉滿了。第二類(lèi)是 JOIN。看 JOIN 類(lèi)型是 HASH JOIN 還是 NESTED LOOP JOIN然后看驅(qū)動(dòng)表是哪一邊。通常驅(qū)動(dòng)表應(yīng)該選小表或過(guò)濾后數(shù)據(jù)量小的一方如果順序反了耗時(shí)會(huì)成倍增長(zhǎng)。還要確認(rèn) JOIN 條件是否完備缺了條件的笛卡爾積是性能殺手這是新手最容易踩的坑。第三類(lèi)是聚合和排序。GROUP BY 的字段數(shù)量直接影響分組開(kāi)銷(xiāo)字段越少越快排序操作如果出現(xiàn)在大數(shù)據(jù)量節(jié)點(diǎn)上會(huì)消耗大量?jī)?nèi)存和臨時(shí)空間。三類(lèi)算子可以整理成一張自查表分析任何執(zhí)行計(jì)劃時(shí)都可以對(duì)著過(guò)一遍算子類(lèi)型關(guān)注點(diǎn)常見(jiàn)性能問(wèn)題TABLE SCAN列存/行存、過(guò)濾下推、分區(qū)裁剪全表掃描、謂詞未下推JOINJOIN 類(lèi)型、驅(qū)動(dòng)表順序、條件完備笛卡爾積、驅(qū)動(dòng)表過(guò)大AGGREGATION / SORTGROUP BY 字段數(shù)量、排序數(shù)據(jù)量分組鍵過(guò)多、內(nèi)存溢出5.4 謂詞下推、分區(qū)裁剪和隱式轉(zhuǎn)換這三個(gè)概念聽(tīng)起來(lái)抽象但它們的共同點(diǎn)是決定了掃描階段到底碰了多少數(shù)據(jù)這是查詢性能的根基。謂詞下推就是 WHERE 條件里的過(guò)濾動(dòng)作能不能提前發(fā)生。理想情況下過(guò)濾應(yīng)該在掃描葉子節(jié)點(diǎn)時(shí)就把大部分行擋掉而不是把大量數(shù)據(jù)一路傳到上層再過(guò)濾。在 PLV 里如果發(fā)現(xiàn)一個(gè)很大的過(guò)濾條件出現(xiàn)在樹(shù)的上層節(jié)點(diǎn)而不是緊貼著掃描節(jié)點(diǎn)就說(shuō)明下推失敗要對(duì)執(zhí)行計(jì)劃做進(jìn)一步分析。分區(qū)裁剪更直白如果表按日期分區(qū)WHERE 里指定了日期范圍執(zhí)行計(jì)劃應(yīng)該只掃描對(duì)應(yīng)分區(qū)。如果 PLV 顯示掃描了全部分區(qū)說(shuō)明分區(qū)鍵沒(méi)有被有效利用。隱式轉(zhuǎn)換是導(dǎo)致前兩個(gè)問(wèn)題失效的元兇。最典型的表現(xiàn)是 WHERE 條件里對(duì)索引列或分區(qū)列套上了函數(shù)或者字段類(lèi)型不匹配導(dǎo)致數(shù)據(jù)庫(kù)悄悄做了類(lèi)型轉(zhuǎn)換。比如WHERE TO_CHAR(ORDER_DATE) 2024-01-15這會(huì)讓數(shù)據(jù)庫(kù)放棄日期分區(qū)裁剪和索引掃描老老實(shí)實(shí)全表掃描。這一類(lèi)問(wèn)題在 PLV 上往往不是一眼能看到的名字而是掃描節(jié)點(diǎn)行數(shù)異常偏大這個(gè)現(xiàn)象。6. 一個(gè)真實(shí)案例高頻短查詢的完整排查鏈路6.1 現(xiàn)象每天下午三點(diǎn)準(zhǔn)時(shí)變慢接手過(guò)一個(gè)某數(shù)據(jù)平臺(tái)的性能問(wèn)題現(xiàn)象非常規(guī)律每天下午三點(diǎn)半左右系統(tǒng)開(kāi)始變慢持續(xù)大約四十分鐘其他時(shí)段一切正常。初期的排查方向集中在后臺(tái)批處理上因?yàn)榕R近下班時(shí)間通常有匯總?cè)蝿?wù)在跑。但從應(yīng)用監(jiān)控來(lái)看批處理按時(shí)啟動(dòng)了數(shù)據(jù)庫(kù)的昂貴語(yǔ)句日志里也沒(méi)有任何超過(guò) 1 秒的查詢監(jiān)控面板上一片祥和用戶卻切切實(shí)實(shí)在報(bào)卡頓。這個(gè)矛盾點(diǎn)正是我前面提到的隱形慢 SQL的典型特征。當(dāng)時(shí)決定不再猜了直接開(kāi) Capture Request Statistics 做全量捕獲。開(kāi)關(guān)在三點(diǎn)前打開(kāi)持續(xù)了一個(gè)半小時(shí)捕獲了一整個(gè)異常時(shí)段。6.2 捕獲數(shù)據(jù)給出的第一輪證據(jù)捕獲結(jié)束后用前面那套聚合查詢把數(shù)據(jù)拉出來(lái)結(jié)果完全出乎意料。Top 排名前四的 SQL 全是 SELECT 語(yǔ)句分別來(lái)自同一個(gè)訂單查詢接口總執(zhí)行次數(shù)驚人——四類(lèi)語(yǔ)句加起來(lái)在 90 分鐘內(nèi)執(zhí)行了近 2 萬(wàn)次平均單次 80 毫秒左右。單看單次耗時(shí)完全不差但累計(jì)總耗時(shí)排到了整個(gè)系統(tǒng)第一位。順著應(yīng)用名追過(guò)去發(fā)現(xiàn)這個(gè)接口被前端頁(yè)面設(shè)置成了每 3 秒輪詢一次而且一個(gè)頁(yè)面同時(shí)會(huì)觸發(fā)多張報(bào)表卡片每張卡片都調(diào)這個(gè)接口。輪詢頻率高本身沒(méi)問(wèn)題問(wèn)題在于這四類(lèi)查詢內(nèi)部都藏著同一個(gè)性能隱患——它們對(duì)訂單主表的掃描方式非常低效幾億行的列存表每次查詢都從最近的分區(qū)開(kāi)始掃。6.3 PLV 揭示的根因函數(shù)包裹索引列把其中耗時(shí)最高的一條 SQL 導(dǎo)出執(zhí)行計(jì)劃在 VS Code 里打開(kāi) PLV。算子樹(shù)一眼看過(guò)去葉子節(jié)點(diǎn)是一個(gè)巨大的 TABLE SCAN掃描行數(shù)幾乎是全表量級(jí)而根節(jié)點(diǎn)耗時(shí)占比高達(dá) 70%。過(guò)濾條件確實(shí)存在但它對(duì)一個(gè)時(shí)間字段做了格式化處理寫(xiě)成了形如TO_CHAR(ORDER_DATE, YYYY-MM-DD) 2024-06-01的條件。這正是典型的隱式轉(zhuǎn)換問(wèn)題。時(shí)間字段是分區(qū)鍵理論上只需要掃一個(gè)分區(qū)但函數(shù)包裹讓優(yōu)化器無(wú)法把等值條件轉(zhuǎn)換成范圍掃描最終選擇了掃描大量分區(qū)甚至全表。類(lèi)似的問(wèn)題還有把字符型字段轉(zhuǎn)成數(shù)值型再比較同樣會(huì)讓索引失效。讀 PLV 到這里根因已經(jīng)非常清楚了。SQL 本身邏輯沒(méi)問(wèn)題是寫(xiě)法沒(méi)有尊重字段的原始類(lèi)型等于親手把優(yōu)化器的手腳綁住了。6.4 改寫(xiě) SQL 之后的效果對(duì)比修復(fù)方式是重寫(xiě) WHERE 條件把函數(shù)移到等號(hào)右側(cè)變成對(duì)常量做處理-- 優(yōu)化前 WHERE TO_CHAR(ORDER_DATE, YYYY-MM-DD) 2024-06-01 -- 優(yōu)化后 WHERE ORDER_DATE TO_TIMESTAMP(2024-06-01 00:00:00) AND ORDER_DATE TO_TIMESTAMP(2024-06-02 00:00:00)改完再看執(zhí)行計(jì)劃葉子節(jié)點(diǎn)的掃描行數(shù)直接下降到原來(lái)的幾十分之一分區(qū)裁剪生效了。對(duì)比捕獲數(shù)據(jù)同一接口查詢的平均耗時(shí)從 80 毫秒降到 9 毫秒由于執(zhí)行次數(shù)不變?cè)摃r(shí)段的總耗時(shí)下降了接近 90%。三天后觀察 CPU 趨勢(shì)下午三點(diǎn)半的峰值完全消失。事后復(fù)盤(pán)給我的啟示是很多高頻短查詢的優(yōu)化收益被嚴(yán)重低估。一條查詢優(yōu)化掉 70 毫秒聽(tīng)起來(lái)不刺激但乘上每小時(shí)幾千次的執(zhí)行頻率就是肉眼可見(jiàn)的 CPU 資源釋放。7. 捕獲與診斷中容易踩的坑7.1 坑一開(kāi)關(guān)開(kāi)了就不關(guān)統(tǒng)計(jì)表瘋漲Capture Request Statistics 一旦開(kāi)啟統(tǒng)計(jì)表的數(shù)據(jù)量增長(zhǎng)很快。高并發(fā)場(chǎng)景下一小時(shí)就可能寫(xiě)入幾十萬(wàn)條記錄長(zhǎng)期不關(guān)會(huì)導(dǎo)致_SYS_STATISTICS模式下的表膨脹反過(guò)來(lái)影響系統(tǒng)性能。我的做法是把開(kāi)啟操作和關(guān)閉操作寫(xiě)在同一條運(yùn)維記錄里并且給捕獲窗口設(shè)置一個(gè)明確的結(jié)束時(shí)間。比如在操作備注里寫(xiě)15:00 開(kāi)啟預(yù)計(jì) 17:00 關(guān)閉。如果確實(shí)需要長(zhǎng)時(shí)間分析也要規(guī)劃定期清理統(tǒng)計(jì)表的策略避免磁盤(pán)和內(nèi)存被歷史數(shù)據(jù)占滿。7.2 坑二排名只看 MAX漏掉高累計(jì)消耗分析捕獲數(shù)據(jù)時(shí)如果只按 MAX 排序會(huì)把注意力引向那些偶爾慢一次的查詢比如月末跑批、定時(shí)報(bào)表。真正持續(xù)消耗系統(tǒng)資源的往往藏在 SUM 排名的前列。這兩種查詢的優(yōu)化價(jià)值完全不同。單次 2 秒、每天跑 5 次的報(bào)表查詢優(yōu)化到 1 秒每天省 5 秒單次 50 毫秒、每分鐘跑 200 次的接口查詢優(yōu)化到 25 毫秒每分鐘省 5 秒一天下來(lái)節(jié)省的時(shí)間是前者的幾十倍。所以不管看哪份報(bào)告我都習(xí)慣把 SUM 作為第一排序字段MAX 只作為參考。7.3 坑三把 EXPLAIN PLAN 的估算計(jì)劃當(dāng)成實(shí)際表現(xiàn)EXPLAIN PLAN輸出的是優(yōu)化器認(rèn)為應(yīng)該怎么跑的計(jì)劃屬于預(yù)演性質(zhì)實(shí)際執(zhí)行時(shí)因?yàn)閿?shù)據(jù)分布、內(nèi)存、并發(fā)等因素計(jì)劃可能完全變樣。我曾經(jīng)犯過(guò)這個(gè)錯(cuò)誤優(yōu)化好一條 SQLEXPLAIN PLAN 看起來(lái)非常完美但上線后性能沒(méi)有提升一查實(shí)際執(zhí)行計(jì)劃優(yōu)化器運(yùn)行時(shí)選擇了另一條低效的路徑。原因是對(duì)某張大表的統(tǒng)計(jì)信息嚴(yán)重過(guò)期優(yōu)化器在真實(shí)環(huán)境中重新評(píng)估后放棄了預(yù)演時(shí)選定的 JOIN 順序。所以驗(yàn)證優(yōu)化效果時(shí)不要停留在 EXPLAIN PLAN 層面最好拿到實(shí)際執(zhí)行計(jì)劃對(duì)比或者直接觀察捕獲數(shù)據(jù)中該 SQL 的真實(shí)耗時(shí)變化。PLV 文件如果來(lái)自實(shí)際執(zhí)行會(huì)標(biāo)注實(shí)際行數(shù)和耗時(shí)可靠性遠(yuǎn)高于純估算計(jì)劃。7.4 我的習(xí)慣把捕獲做成季度巡檢的一部分這套方法我并不僅用于應(yīng)急排查更多時(shí)候用于例行巡檢。每季度挑一個(gè)業(yè)務(wù)周期開(kāi)啟一到兩天捕獲把 Top SQL 清單導(dǎo)出來(lái)存檔再和上一輪的結(jié)果對(duì)比。哪些新查詢進(jìn)入了 Top哪些舊查詢的耗時(shí)在下滑哪些查詢的執(zhí)行次數(shù)在悄悄上漲都一目了然。這個(gè)習(xí)慣幫我在故障發(fā)生前發(fā)現(xiàn)過(guò)不少隱患。比如某條老查詢本來(lái)平均 20 毫秒連續(xù)兩個(gè)季度慢慢漲到了 120 毫秒單次不慢總量卻翻了好幾倍順著統(tǒng)計(jì)表一查原來(lái)是底層表數(shù)據(jù)量膨脹現(xiàn)有索引選擇性變差。如果等到用戶報(bào)障再查可能已經(jīng)是高峰期扛不住的臨界點(diǎn)。我自己最深的體會(huì)是診斷 SAP HANA 性能問(wèn)題Capture Request Statistics 和 PLV 是一對(duì)組合拳前者負(fù)責(zé)把真兇從海量請(qǐng)求里撈出來(lái)后者負(fù)責(zé)把犯罪動(dòng)機(jī)從算子樹(shù)里挖出來(lái)。缺了第一步你只是在瞎猜缺了第二步你知道是誰(shuí)卻不知道怎么改。按這套流程走下來(lái)大多數(shù)性能問(wèn)題都能在半小時(shí)內(nèi)給出明確結(jié)論。