實戰案例：聯合索引與 WHERE 條件順序優化，將 48 秒慢查詢降至 0.28 秒

現場還原

• 數據量 500MB、8 萬行，查詢含多表 JOIN + ORDER BY；
• 原耗時 48 秒，去掉 ORDER BY 後 0.3 秒 → 瓶頸在排序；
• 為排序列建立聯合索引 INDEX idx_sort (x1, x2, x3)，重跑 0.28 秒，問題解決。

副作用與再優化

30 分鐘後另一條原本快的 SQL 變慢，經排查因新增聯合索引導致含 OR 條件的查詢走錯計劃。將 OR 改寫為 UNION ALL 後恢復正常。

教訓：索引雙刃劍，新增索引後必須全量回歸測試核心 SQL。

WHERE 條件順序同樣關鍵

-- 原寫法：首條件過濾性差，返回數萬行再逐步縮小
WHERE p.languages_id = 1 
  AND m.languages_id = 1 
  AND c.languages_id = 1 
  AND t.languages_id = 1 
  AND p.products_id IN (472,474)

-- 優化後：首條件高選擇性，直接定位極少行
WHERE p.products_id IN (472,474)
  AND p.languages_id = 1 
  AND m.languages_id = 1 
  AND c.languages_id = 1 
  AND t.languages_id = 1

MySQL 按 WHERE 順序依次應用條件（優化器可能重排，但實測順序影響大），首條件應盡可能過濾掉 99%+ 無效行。

核心心法

1. 為 ORDER BY/GROUP BY 列建聯合索引，順序與排序一致；
2. 避免 OR，改用 UNION ALL；
3. WHERE 條件高選擇性列前置；
4. 新增索引後跑全量慢查詢回歸。