善用 STRAIGHT_JOIN 強制連接順序：解決 MySQL 優化器選錯驅動表導致的排序性能問題

STRAIGHT_JOIN 實戰：強制連接順序消除 Using filesort

問題場景

多表關聯查詢耗時 5s+，EXPLAIN 顯示 Using temporary; Using filesort，排序字段 published_at 有索引卻未被使用。優化器選擇 channels_news 作為驅動表（16 萬行），導致排序在臨時表進行。

優化前 SQL（簡化）

SELECT * FROM news n0_
INNER JOIN news_translations n1_ ON n0_.id = n1_.translatable_id
INNER JOIN channels_news c3_ ON n0_.id = c3_.news_id
WHERE ... ORDER BY n0_.published_at DESC LIMIT 5;

EXPLAIN 關鍵差異

解決方案：STRAIGHT_JOIN

SELECT * FROM news n0_
STRAIGHT_JOIN news_translations n1_ ON n0_.id = n1_.translatable_id
STRAIGHT_JOIN channels_news c3_ ON n0_.id = c3_.news_id
WHERE ... ORDER BY n0_.published_at DESC LIMIT 5;

STRAIGHT_JOIN 強制按書寫順序連接，使 news 成為驅動表，排序直接利用索引，避免臨時表與 filesort。

原理深度解析

• MySQL 優化器傾向「小表驅動大表」以減少嵌套循環成本。
• 但當 ORDER BY 字段不在驅動表上時，需建立臨時表排序，產生巨大開銷。
• 人為指定驅動表為排序字段所在表，可直接利用索引有序性。

注意事項

• 慎用：優化器通常更優，僅在確定優化器選錯且經測試驗證後使用。
• 數據分布變化可能導致強制順序反而變差，需定期複核。
• 替代方案：優化索引（覆蓋索引）、重寫查詢、調整 optimizer_switch。

總結

本案例中，STRAIGHT_JOIN 將查詢從 5s 降至 0.02s，展示了強制連接順序在特定場景下的威力，但務必以測試數據為準，避免過度優化。