效能調查 · SQL

週五晚上的慢 API，別先開一張「加索引」單。

假設結帳 API 在晚間尖峰變慢。值班的人需要的是可重現的線索：哪一種查詢一直出現、它打到哪張表、計畫到底做了什麼；不是靠感覺補一個索引。

這次要查的事：監控顯示結帳 API 的延遲上升，但錯誤率沒變。先別把「訂單很多」當原因。這個流程把本機觀測、orders 的實際結構與查詢計畫排在一起，讓下一步有依據。

把猜測縮成可審查的問題

先確認是不是同一種查詢在拖慢

proxy analyze 把已記錄事件按 fingerprint、耗時、錯誤和熱門資料表整理。它只讀本機觀測資料，適合先回答「哪一條值得追」。

dbcli proxy analyze --format json --top 10

找到了候選查詢，再看真正的表與計畫

如果最慢的 fingerprint 指向訂單查詢，先確認 orders 現在的欄位，再用 explain 看資料庫的執行證據。這能分開「查詢寫錯」和「資料量真的變了」。

dbcli schema orders --format json
dbcli explain "@saved-query" --format markdown

建議是下一張審查材料，不是自動修復

確認了查詢和表結構後，才產生缺失索引建議。它可以進 migration review，但還要評估寫入成本、鎖定和部署時機，才決定是否形成 DDL。

dbcli guide missing-index-for "@saved-query" --format json
dbcli skill tasks plan migration-review \
  --param "table=<精確資料表名稱>" \
  --param "ddl=<已擷取的 dry-run DDL>"