ORDER BY、GROUP BY、DISTINCT 等操作消耗大量 CPU,IO 優化到瓶頸後再著手。所有優化最終都指向讓優化器選擇更優的執行計劃,避免全表掃描、減少回表、利用索引排序等。
| 誤區 | 真相 |
|---|---|
count(1)/count(pk) 優於 count(*) | MySQL 對 count(*) 有特殊優化,某些場景反而更快 |
count(col) = count(*) | 前者統計非 NULL 行數,後者統計總行數,語義與執行計劃均不同 |
| 少選列可減少 IO | 行存儲下,整行讀入 IO 單元(page/block),除非覆蓋索引才能減少 IO |
ORDER BY 必然排序 | 若數據已按索引順序滿足排序,優化器會省略 filesort |
Explain 出現 filesort 即磁盤排序 | 只要需排序必現 Using filesort,不代表落盤,可能在記憶體完成 |
SELECT *:尤其配合 ORDER BY 時會擴大排序緩衝區,且失去覆蓋索引機會;OR:優化器處理 OR 能力弱,改用 UNION ALL;UNION ALL 而非 UNION:前者無去重排序開銷;對每條運行中的 SQL 執行 EXPLAIN,收集執行計劃,建立基線,持續迭代優化。