MySQL 查詢優化實戰：Informax 案例深度解析

查詢優化核心觀念

資料庫系統為管理資訊核心，OLTP 與 OLAP 為關鍵應用。查詢操作佔比最高，SELECT 代價最大。百萬級資料全表掃描耗時數十分鐘，優良策略可降至數分鐘。

許多開發者僅重介面忽略查詢效率，導致系統低效。本文結合實務案例與理論，以 Informix 為例闡述優化技巧。

誤區澄清

誤以為優化是 DBMS 責任。事實：良好查詢計畫可提升數十倍效能。DBMS 流程：語法檢查 → 查詢最佳化器（代數優化 + 存取路徑優化） → 預編譯產生規劃 → 執行。主流資料庫採基於成本優化，但用戶 SQL 為基礎，糟糕查詢難經系統優化變高效。

三大解決方案

1. 合理使用索引

• 經常 JOIN 但非外鍵欄位建索引；不常連接欄位讓最佳化器自動處理
• GROUP BY/ORDER BY 高頻欄位建索引
• 條件表達式中高基數欄位建索引；低基數（如性別）勿建，反而嚴重拖慢更新
• 多欄位排序建複合索引
• 善用系統工具（Informix tbcheck）檢查索引完整性；大量更新後刪除重建索引提速

2. 避免或簡化排序

大型表重複排序代價高。最佳化器若能利用索引順序輸出則省略排序。影響因素：

• 索引未包含待排序欄位
• GROUP BY/ORDER BY 順序與索引不符
• 排序欄位來自不同表

對策：正確增建索引、合理合併表（犧牲正規化換效率）、不可避免時縮小排序範圍。

3. 消除大型表循序存取

巢狀查詢中循序存取可能造成災難：3 層巢狀各 1000 行即產生 10 億行掃描。核心解法：對連接欄位建索引。例：學生表與選課表以「學號」連接，必須在學號建索引。

亦可用 UNION 避免循序存取。某些 WHERE 子句會強迫最佳化器採循序存取，需注意改寫。例如：

SELECT * FROM orders WHERE (customer_num = 100 OR customer_num = 200)
# 可能強迫 orders 表循序掃描