MySQL 視圖優化實戰：從 30 分鐘到 0.08 秒，EXPLAIN 定位 Using filesort 根因

現場還原：一個跑不完的視圖

開發反饋某視圖 SELECT 需要 1987 秒（33 分鐘），返回 21068 行。EXPLAIN 顯示 Using filesort，排序開銷極大。

優化歷程：三步定位根因

第一步：關注 WHERE 子查詢

初步嘗試優化 WHERE 後的子判斷，將 SELECT MAX(ol2.ID) 等改寫，但效果微乎其微。

第二步：深度剖析視圖結構——恍然大悟

視圖定義中存在多層嵌套子查詢 + 不必要的排序，導致優化器無法下推條件，被迫全量掃描後文件排序。

第三步：重寫視圖——算法重構

CREATE ALGORITHM=UNDEFINED 
SQL SECURITY DEFINER 
VIEW view_offer_label AS
SELECT 
  ol.OFFER_ID,
  ol.EFFECTIVE_DATE,
  ...
FROM offer_label ol
JOIN (
  SELECT offer_id, MAX(id) AS max_id
  FROM offer_label_history
  GROUP BY offer_id
) olh ON ol.OFFER_ID = olh.offer_id
WHERE ol.STATUS = 1
  AND ol.EFFECTIVE_DATE <= NOW();

關鍵改動：

• 將相關子查詢轉為 派生表 JOIN，利用派生表物化避免重複掃描。
• 移除視圖內部 ORDER BY，交由外層應用按需排序。
• 添加覆蓋索引：INDEX idx_status_date (STATUS, EFFECTIVE_DATE)。

驚人結果

21068 rows in set (0.08 sec)

性能提升 24,837 倍，從「跑報表喝杯咖啡」到「毫秒級響應」。

核心心法：視圖優化三板斧

1. EXPLAIN 視圖查詢：關注 Using filesort、Using temporary、Derived table 關鍵字。
2. 拆解視圖定義：將視圖 SQL 獨立執行 EXPLAIN，定位哪個子查詢/關聯導致全掃描。
3. 重構而非修補：視圖嵌套超過 2 層、含聚合/排序/UNION 時，直接重寫為 JOIN + 派生表/物化表，避開優化器短板。

避坑清單

總結

視圖是邏輯封裝層，不是性能免死金牌。複雜視圖必須像對待核心 SQL 一樣嚴格 Review、EXPLAIN、壓測。這次優化，0 行業務代碼變更，僅重構視圖定義，即獲數萬倍收益——這就是數據庫治理的杠桿效應。