業務背景

• 網絡審計系統，HTTP 協議日誌表單日 4000 萬行，.MYD 達 8 GB+
• 多字段條件查詢（含 256 字元長字串），原查詢 20-30 分鐘無結果
• 一天一表，三個月保留 90+ 表，30 協議模組共 2700+ 表

優化演進路徑

階段一：常規索引優化（效果有限）

• 時間欄位加索引（8 bytes × 4000 萬 = 320 MB 索引體積）
• 效果：略有提升，但多條件組合查詢仍慢
• 痛點：全字段建索引會使索引體積接近資料體積，寫入效能驟降

階段二：分段查詢（犧牲易用性換效能）

• 前端提供下拉：0-400萬、400-800萬 ... 3600-4000萬
• 後端按 id BETWEEN start AND end 切分
• 單段查詢控制在 30 秒內
• 缺點：用戶需手動翻頁、跨段統計不可用

階段三：一級預統計（前人遺產）

• 定時任務將日誌聚合為「月統計表」
• 查詢統計報表時直接查預統計表
• 問題：流量增長導致月統計表同樣達 4000 萬行，查詢仍慢

階段四：二次預統計（終極解決）

• 在月統計表基礎上，按業務維度（客戶、協議、應用）再聚合
• 最終查詢面對的表僅幾千行，毫秒級返回
• 代價：寫入鏈路延長、存儲成本增加、數據有分鐘級延遲

核心心得

「當資料庫層面優化觸及天花板時，**改變使用模式、調整業務流程**往往比硬拼 SQL 調優更有效。」

團隊協作模式

1. 全員參與壓測、分析慢查詢日誌、定位瓶頸
2. 集體腦暴方案，評估利弊，達成共識
3. 分工實施：DBA 調參、開發改查詢、運維調架構
4. 灰度驗證，全量上線

避坑指南

• 不要為了「完美即時」犧牲可用性，業務通常能接受「近實時」
• 預統計維度設計要覆蓋 80% 以上高頻查詢場景
• 保留原始明細滿足審計/回溯需求，預統計服務前端展示

此案例證明：**大數據量下的查詢優化，本質是「計算搬遷」——將計算從查詢時搬遷到寫入時或離線批次時。**