CTO 如何在 20 分鐘內找出慢查詢並在財務升級前修復
NeonEdge 是一個以密碼貨幣為原生的 iGaming 平台，總部位於愛沙尼亞塔林，以支援 ETH、Tron、Polygon 和 SOL 多鏈的可驗公平 Crash 遊戲為核心。平台每月約有一萬五千名活躍用戶，每週產生約 500 萬美元的 GGR。這是一個精幹、技術雄心勃勃的團隊——兩名工程師負責整個數據基礎設施——而 Priya Desai，CTO 兼數據負責人，是產品和財務遇到任何問題時第一個打電話的人。
使用產品：查詢效能分析、基礎設施監控、成本優化
20 分鐘 | 完整調查時間
3 | 從零開始識別出的問題查詢數量
12 倍 | 優化部署後的平均提速倍數
挑戰
投訴在四十八小時內從兩個不同方向同時湧入。產品團隊在 Slack 上反映玩家活動報表感覺很遲鈍——「有時候點了就等，然後就放棄了。」財務部門說得更直白：每週 GGR 對帳報表已開始在載入中途超時，CFO 只好在頁面崩潰前截圖保存半渲染的畫面。沒有錯誤代碼，沒有明顯故障——只是緩慢，已悄悄從令人煩惱跨越到真正出問題的界線。
Priya 處理這類問題的標準診斷工具並不快速。在多鏈數據棧中追蹤查詢延遲，意味著要關聯三個獨立服務的日誌、手動檢查叢集資源使用率，並重建哪個上游轉換為哪個下游報表增加了時間。順利的情況下，若日誌已提前浮現，這需要兩到三小時；糟糕的情況——慢查詢只在高負載下出現——可能拖整個下午。
結構性問題在於 NeonEdge 的數據棧是自然生長的。早期在五千 MAU 時做出的工程決策，在平台突破一萬五千後從未被重新審視。沒有人刻意決定跳過索引，或在核心報表中寫入全表掃描；這只是在團隊專注於功能交付而非審計數據訪問模式時，逐漸發生的。
「我們是一個兩人數據團隊，為一萬五千名用戶和每週五百萬美元 GGR 的基礎設施服務。我沒有奢侈的時間花一整天追一個慢查詢。我需要在二十分鐘內看到瓶頸，否則問題就等到下個 Sprint。」
— Priya Desai，CTO，NeonEdge
解決方案
Priya 打開 Gaming Mind AI，用簡單的語言描述了症狀：報表很慢，沒有人知道是哪個查詢的問題，問題已升級兩天。Gaming Mind 連接到 NeonEdge 的基礎設施遙測，從最直接的診斷問題開始——哪些查詢目前正在消耗整個棧中最多的執行時間。
以下是調查的展開過程：
Priya：「報表全面變慢。我應該先看哪裡？」
| 排名 | 查詢名稱 | 平均執行時間 | p99 時間 | 每日執行次數 | 調用方 | 佔總查詢時間 % |
|---|---|---|---|---|---|---|
| 1 | GGR 對帳報表 | 41.2 秒 | 68.4 秒 | 4 | 財務 | 24% |
| 2 | 玩家活動報表 | 31.0 秒 | 54.1 秒 | 8 | 產品 | 22% |
| 3 | 玩家群組報表 | 28.3 秒 | 47.6 秒 | 6 | 產品 / CRM | 12% |
| 4 | 聯盟商收益歸因 | 5.8 秒 | 11.2 秒 | 12 | 市場 | 4% |
| 5 | 每日活躍用戶匯總 | 5.1 秒 | 9.7 秒 | 24 | 運營 | 4% |
| 6 | 鏈結算對帳 | 4.9 秒 | 9.1 秒 | 6 | 財務 | 3% |
| 7 | 流失風險評分刷新 | 4.4 秒 | 8.3 秒 | 2 | CRM | 2% |
| 8 | 錢包餘額快照 | 3.8 秒 | 7.2 秒 | 48 | 運營 | 2% |
| 9 | 紅利使用率報表 | 3.2 秒 | 6.4 秒 | 4 | 產品 | 1% |
| 10 | 新註冊漏斗 | 2.9 秒 | 5.8 秒 | 24 | 市場 | 1% |
| （其餘所有） | — | < 2.0 秒 | < 4.0 秒 | — | 各部門 | 25% |
| 前 3 名合計 | 約 100 秒（合計） | 58% | ||||
| 前 10 名合計 | 71% |
⚠️ Gaming Mind flags：前 3 個查詢佔總查詢執行時間的 58%。分佈嚴重不均——查詢 1–3 各平均 28–41 秒，而查詢 4–10 合計平均不到 6 秒。修復前 3 個查詢，預計可在不觸及其他任何內容的情況下，將總查詢時間減少約 58%。
Gaming Mind 的第一個回應是過去七天查詢執行時間的排名排行榜。前十名最慢的查詢佔總執行時間的 71%，但分佈極不均衡——最差的三個平均每個耗時 28 到 41 秒，而第四到第十名合計平均不到六秒。Gaming Mind 標記前三名為唯一值得立即調查的對象：修復它們預計可在不觸及其他任何內容的情況下，將總查詢時間減少約 58%。Priya 在九十秒內就有了起點。
Priya：「告訴我最慢的那個。」
查詢：GGR 對帳報表
| 階段 | 操作 | 掃描行數 | 輸出行數 | 階段時間 | 累計時間 |
|---|---|---|---|---|---|
| 1 | 全表掃描——transaction_ledger | 84,200,000 | 84,200,000 | 28.4 秒 | 28.4 秒 |
| 2 | 篩選：本週記錄 | 84,200,000 | 312,400 | 6.1 秒 | 34.5 秒 |
| 3 | 關聯：鏈元數據 | 312,400 | 312,400 | 2.8 秒 | 37.3 秒 |
| 4 | 聚合：按鏈 + 遊戲類型統計 GGR | 312,400 | 48 | 1.9 秒 | 39.2 秒 |
| 5 | 格式化輸出 | 48 | 48 | 2.0 秒 | 41.2 秒 |
| 診斷項目 | 詳情 |
|---|---|
| 掃描的數據日期範圍 | 平台上線（18 個月）至今 |
| 所需日期範圍 | 僅當週 |
| 掃描前是否應用日期篩選 | 否 |
| 訪問模式分類 | 未篩選的歷史掃描 |
| 嚴重程度 | 🔴 高——追加型帳本架構中已知的效能反模式 |
| 根本原因 | 全表掃描前缺少 WHERE 日期謂詞——18 個月前的設計決策從未重新審視 |
⚠️ Gaming Mind flags：GGR 對帳報表——正是財務投訴的那個查詢——為了回答一個只需要當週數據的問題，正在對 18 個月的交易歷史進行全表掃描。在掃描前應用日期篩選是唯一需要的修復。這是財務 CFO 超時的根本原因。
最慢的查詢是 GGR 對帳報表——正是財務投訴的那個。Gaming Mind 逐階段分解其執行計劃：一個全表掃描每次執行都會觸及交易帳本中的每一行，包括從平台上線起的歷史記錄。查詢在掃描前沒有應用日期篩選，這意味著每次需要回答只涉及當週的問題時，它都在處理近十八個月的交易歷史。Gaming Mind 將此歸類為高嚴重性訪問模式，並標記為「未篩選的歷史掃描」——追加型帳本架構中已知的效能反模式。根本原因是十八個月前的一個從未被重新審視的設計決策。
Priya：「第二個查詢發生了什麼？」
查詢：玩家活動報表
| 階段 | 操作 | 輸入行數 | 輸出行數 | 階段時間 | 累計時間 |
|---|---|---|---|---|---|
| 1 | 掃描：player_sessions | 2,100,000 | 2,100,000 | 4.2 秒 | 4.2 秒 |
| 2 | 關聯：game_events（寬連結，篩選前） | 2,100,000 | 18,700,000 | 12.8 秒 | 17.0 秒 |
| 3 | 關聯：wallet_activity | 18,700,000 | 18,700,000 | 7.1 秒 | 24.1 秒 |
| 4 | 篩選：玩家群組 + 日期範圍 | 18,700,000 | 480,000 | 4.6 秒 | 28.7 秒 |
| 5 | 聚合 + 格式化 | 480,000 | 920 | 2.3 秒 | 31.0 秒 |
| 診斷項目 | 詳情 |
|---|---|
| 瓶頸階段 | 第 2 階段——關聯在篩選縮小前先擴展 |
| 中間結果集峰值 | 18,700,000 行（約為必要大小的 3 倍） |
| 原因 | 關聯順序將寬關聯置於最窄篩選之前 |
| 修復 | 在與 game_events 關聯前先應用玩家群組 + 日期篩選 |
| 修復後預計中間大小 | 約 6,200,000 行 |
| 修復後預計執行時間 | < 5 秒 |
| 記憶體減少量 | 約 66% |
⚠️ Gaming Mind flags：玩家活動報表的關聯在篩選前先擴展——產生的中間結果集比必要大小大約 3 倍。顛倒關聯序列中的兩個步驟（先應用最窄的篩選）將把中間記憶體消耗減少約三分之二，並將執行時間從 31 秒降至 5 秒以下。
第二個問題查詢為產品團隊標記的玩家活動報表提供數據。Gaming Mind 識別出一個多階段關聯——它在篩選前先擴展，在按玩家群組和日期範圍縮小之前，以峰值大小處理寬中間結果集。關聯順序產生的中間表比必要大小大了近三倍。Gaming Mind 標注了結果集膨脹的確切階段，並估計顛倒關聯序列中的兩個步驟——先應用最窄的篩選——將把中間記憶體消耗減少約三分之二，並將執行時間從三十一秒降至五秒以下。
Priya：「第三個呢？」
查詢：玩家群組報表
| 欄位 | 是否存在單一索引 | 是否為複合索引的一部分 | 基數 | 解析交集所花時間 |
|---|---|---|---|---|
| chain_identifier | 是 | 否 | 低（4 個值） | — |
| registration_date | 是 | 否 | 高（540 天） | — |
| game_category | 是 | 否 | 中（12 個值） | — |
| chain_identifier + registration_date + game_category | 否 | 否 | — | 每次執行約 19 秒 |
| 診斷項目 | 詳情 |
|---|---|
| 缺失的索引類型 | （chain_identifier, registration_date, game_category）的複合索引 |
| 當前解析方法 | 查詢時手動求交集 |
| 添加複合索引後的預計執行時間 | < 3 秒 |
| 平台中使用此欄位組合的查詢數 | 14 個不同查詢 |
| 添加 1 個複合索引後額外加速的查詢數 | 13 |
| 嚴重程度 | 🔴 高——單一修復，影響整個平台 |
⚠️ Gaming Mind flags：在此查詢的每個版本中都出現的三個欄位——chain_identifier、registration_date 和 game_category——各自都有索引，但從未作為複合索引。添加一個複合索引將消除手動求交集的工作，同時加速群組報表以及平台上的另外 13 個查詢。
第三個慢查詢是玩家群組報表，每週由產品和 CRM 團隊使用。Gaming Mind 找到了一個索引覆蓋缺口：在此查詢的每個版本中一起出現的三個欄位——鏈識別符、註冊日期和遊戲類別——各自都有索引，但從未作為複合索引。每次執行都在查詢時手動解析交集，做著單個複合索引本可完全消除的工作。Gaming Mind 指出，這個欄位組合出現在平台上的十四個不同查詢中，意味著添加單個索引將同時加速群組報表和另外十三個查詢。
Priya：「在這些查詢執行期間，向我展示叢集的資源消耗情況。」
14 天資源使用情況——計劃報表視窗峰值
| 日期 | 報表視窗 | CPU 峰值 | 記憶體峰值 | I/O 峰值 | 並發慢查詢數 | 是否發生隊列級聯？ |
|---|---|---|---|---|---|---|
| 第 1 天 | 09:00–09:45 | 74% | 71% | 68% | 1 | 否 |
| 第 2 天 | 09:00–09:45 | 78% | 76% | 72% | 1 | 否 |
| 第 3 天 | 09:00–09:45 | 81% | 79% | 75% | 2 | 否 |
| 第 4 天 | 09:00–09:45 | 76% | 74% | 71% | 1 | 否 |
| 第 5 天 | 09:00–09:45 | 82% | 89% | 84% | 2 | 是 |
| 第 6 天 | 09:00–09:45 | 77% | 75% | 73% | 1 | 否 |
| 第 7 天 | 09:00–09:45 | 79% | 77% | 74% | 1 | 否 |
| 第 8 天 | 09:00–09:45 | 83% | 89% | 85% | 2 | 是 |
| 第 9 天 | 09:00–09:45 | 75% | 73% | 70% | 1 | 否 |
| 第 10 天 | 09:00–09:45 | 84% | 91% | 87% | 2 | 是 |
| 第 11–14 天 | 09:00–09:45 | 72–78% | 70–76% | 67–73% | 0–1 | 否 |
風險摘要
| 指標 | 數值 |
|---|---|
| 並發慢查詢執行時的記憶體上限 | 89–91% |
| 過去 10 天的級聯事件次數 | 3 |
| 級聯觸發條件 | GGR 對帳與玩家活動報表並發執行 |
| 風險分類 | 🔴 叢集穩定性風險 |
⚠️ Gaming Mind flags：每一次 CPU 和 I/O 使用率峰值都與計劃報表執行時間重合。在過去 10 天中，有 3 次 GGR 對帳和玩家活動報表並發執行，將記憶體推至 89% 以上，觸發了波及其他工作負載的隊列延遲——包括財務 CFO 的超時。這不僅僅是一個慢查詢問題。這是叢集穩定性風險。
Gaming Mind 將三個慢查詢視窗疊加到 NeonEdge 過去兩週的叢集資源熱力圖上。模式一目了然：每次 CPU 和 I/O 使用率峰值都與計劃報表執行時間重合，且叢集在前兩個查詢並發執行期間，記憶體幾乎達到容量上限。在過去十天中，有三次 GGR 對帳和玩家活動報表並發執行，將記憶體使用率推至 89% 以上，觸發了波及其他工作負載的查詢隊列延遲——包括 CFO 遭遇的財務超時。這不僅僅是慢查詢問題。這是叢集穩定性風險。
Priya：「我應該如何優先排序這三個修復？先做哪個？」
| 修復 | 查詢 | 預計提速 | 實施難度 | 部署風險 | 影響的查詢數 | 建議順序 |
|---|---|---|---|---|---|---|
| 添加複合索引（chain_id + reg_date + game_cat） | 玩家群組報表 | 約 9 倍 | 低（< 1 小時） | 非常低 | 14 個查詢 | 第 1 位——今天部署 |
| 重寫關聯順序（篩選後再擴展） | 玩家活動報表 | 約 6 倍 | 中（3–4 小時） | 低（在暫存環境測試） | 1 個查詢 | 第 2 位——暫存後部署 |
| 在全表掃描前添加日期謂詞 | GGR 對帳報表 | 約 12 倍 | 中（2–3 小時） | 中（財務計劃依賴性） | 1 個查詢 + 緩存資格 | 第 3 位——下次財務維護視窗 |
評分詳情
| 修復 | 提速評分 | 難度評分 | 風險評分 | 影響廣度評分 | 總優先度評分 |
|---|---|---|---|---|---|
| 複合索引 | 3/5 | 5/5 | 5/5 | 5/5 | 18/20 |
| 關聯重寫 | 4/5 | 3/5 | 4/5 | 2/5 | 13/20 |
| 日期謂詞 | 5/5 | 3/5 | 3/5 | 3/5 | 14/20 |
⚠️ Gaming Mind flags：優先部署複合索引——風險最低、實施最快、對平台 14 個查詢的正面影響最廣。GGR 關聯重寫的個別提速最高（預計 12 倍），但需要針對財務的確切報表參數進行暫存驗證。全表掃描修復必須在部署前與財務協調維護視窗。
Gaming Mind 製作了一個優先級矩陣，在四個維度上對每個修復進行評分：預計提速、實施複雜度、部署風險以及下游影響的廣度。複合索引排名第一——風險最低、部署最快，且對平台十四個受影響查詢的正面影響最廣。GGR 關聯重寫排名第二：個別提速最高，預計十二倍提升，但需要針對財務的確切報表參數進行仔細的測試，才能部署。未篩選全表掃描修復排名第三——影響也很高，但涉及對財務固定每週計劃運行的報表進行日期篩選更改，這意味著需要協調部署視窗。Gaming Mind 建議先部署索引，在暫存中測試關聯重寫，並將全表掃描修復安排在下次財務維護視窗中。
Priya：「如果我修復全部三個，預計總提速是多少？」
優化後的預計效能
| 查詢 | 修復前 | 修復後 | 提速 |
|---|---|---|---|
| GGR 對帳報表 | 41.2 秒 | 3.4 秒 | 約 12 倍 |
| 玩家活動報表 | 31.0 秒 | 4.8 秒 | 約 6 倍 |
| 玩家群組報表 | 28.3 秒 | 3.1 秒 | 約 9 倍 |
| 平均報表生成（合計） | 45.0 秒 | < 4.0 秒 | > 11 倍 |
叢集資源餘量
| 指標 | 修復前 | 修復後 | 變化 |
|---|---|---|---|
| 記憶體使用率（並發報表執行） | 89%（上限） | 約 34% | -55 個百分點 |
| 每 10 天的隊列級聯事件 | 3 | 0（預計） | 消除 |
| CFO 報表超時風險 | 存在 | 無 | 消除 |
次要效益——GGR 對帳緩存
| 詳情 | 數值 |
|---|---|
| 修復後緩存資格 | 是（日期謂詞啟用預計算） |
| 預計每月運算成本降低 | 約 60% |
| 標記此效益的模組 | 成本優化 |
⚠️ Gaming Mind flags：三個修復合計預計將平均報表生成時間從 45 秒降至 4 秒以下——降幅超過 90%。峰值計劃執行期間的叢集記憶體將從 89% 降至約 34%，完全消除級聯隊列風險。GGR 對帳修復還解鎖了預計算緩存資格，預計可將該報表的每月運算支出減少約 60%。
Gaming Mind 對合併效果進行了建模。三個修復合計預計將平均報表生成時間從四十五秒降至四秒以下——降幅超過九十%。峰值計劃執行期間的叢集記憶體使用率預計從當前 89% 的上限下降至約 34%，完全消除隊列級聯風險。預測還標記了一個次要效益：隨著未篩選全表掃描問題解決，GGR 對帳報表將有資格進行預計算緩存，Gaming Mind 的成本優化模組估計這將每月減少約六十%的該報表運算支出。
「我走進去以為要在日誌檔案裡花一下午。Gaming Mind 在二十分鐘內就把三個查詢排好名次、分析完畢、並按優先順序列出修復清單。甚至告訴我按什麼順序修復。我只需要寫代碼。」
— Priya Desai
成果
從零開始，20 分鐘內完成調查
Priya 沒有預建的查詢效能儀表板，也沒有可追蹤的開放事件。Gaming Mind 提取了遙測數據，對違規者進行了排名，並在一次對話中生成了按部署順序排列的修復清單。零個日誌檔案打開，零個支援工單提交，零個工程師從其他工作中抽調。
三個根本原因，跨越三種不同問題類型
每個慢查詢都有結構上不同的原因——未篩選的歷史掃描、次優的關聯順序以及缺失的複合索引。Gaming Mind 診斷了全部三個問題，並用 Priya 可以直接向工程團隊傳達的通俗語言解釋了每一個，無需翻譯。調查浮現了幾個月來一直在積累的問題，而不僅僅是過去四十八小時內報告的症狀。
修復部署後平均提速 12 倍
複合索引當天下午就上線了。關聯重寫在當天結束前通過了暫存測試，次日早上部署。全表掃描修復與財務協調後，在下次維護視窗中部署。三個更改全部完成後，平均報表生成時間從四十五秒降至三秒四十二秒——根據平台自身遙測測量，提升了十二倍。
叢集穩定性風險在演變成事件前被消除
在並發報表執行期間，記憶體使用率上限——一直悄悄逼近 89%——在修復後降至 34%。過去十天發生的三次級聯事件，是叢集在高負載下接近故障的早期預警信號。Gaming Mind 從資源熱力圖分析中浮現了這個風險；如果沒有它，下一個事件很可能是高流量週末時段的全面報表中斷。
對帳報表的每月運算成本預計降低 60%
成本優化模組標記了 GGR 對帳報表修復後的預計算緩存資格。Priya 的團隊在初始修復後兩週實施了緩存層，次月該報表工作負載的基礎設施費用為之前基準的三十八%——略好於預期。
「叢集距離真正中斷只差三個糟糕的週日，而我們不知道。效能調查找到了慢查詢，但資源熱力圖找到了穩定性風險。那才是真正讓我害怕的部分——也是我最慶幸在它找到我們之前，我們先找到了它。」
— Priya Desai，CTO，NeonEdge
Read in another language
Want to see how Gaming Mind AI can help your operation?
Get a Demo