MySQL 派生表與視圖性能大比拼：為什麼視圖完勝派生表？

背景：從 4.1 到 5.0 的演進

MySQL 4.1 引入派生表（即 FROM 子句中的子查詢），5.0 再添視圖。兩者看似相近，實際執行路徑卻天差地別。

核心差異：物化 vs 查詢重寫

實測對比：性能懸殊

-- 基表查詢（有索引）：0.03 秒
SELECT * FROM test WHERE i=5;

-- 派生表查詢：1 分 40 秒！全表掃描臨時表
SELECT * FROM (SELECT * FROM test) t WHERE i=5;

-- 視圖查詢：0.10 秒，索引生效
CREATE VIEW v AS SELECT * FROM test;
SELECT * FROM v WHERE i=5;

EXPLAIN 驚人對比：

• 視圖：type=const，走主鍵，rows=1
• 派生表：type=ALL，掃描 163 萬行臨時表，EXPLAIN 本身耗時 54 秒

實戰避坑指南

1. 能不用派生表就不用：改寫為 JOIN、UNION 或多步驟查詢通常更快。
2. 臨時表替代法：若必須用子查詢，手動創建帶索引的臨時表往往比派生表快。
3. 臨時視圖策略：查詢前 CREATE VIEW，查詢後 DROP VIEW，兼顧代碼結構與性能。

期待修復

同語義查詢因語法形式不同導致數量級性能差異，屬於優化器邏輯缺陷，期待後續版本統一處理路徑（如 5.6+ 引入的 derived_merge 優化已部分緩解）。