MySQL SQL 優化實戰：關聯子查詢效能陷阱與改寫策略

業務系統頻繁出現執行 286~480 秒的慢 SQL，統計發現外層表 t1 掃描 90 萬列，根因是 MySQL 優化器將關聯子查詢的外層表「下推」到子查詢內部，導致大表全掃描。本文剖析優化器局限性與改寫方案。

問題 SQL 模型

SELECT * FROM t1
WHERE col1 IN (SELECT col2 FROM t2 WHERE t2.id = t1.id);

MySQL 會將 t1 逐列代入子查詢執行，等同於 Nested Loop Join，若 t1 為大表則災難性。

優化器行為分析

• MySQL 5.6/5.7 對 IN/EXISTS 關聯子查詢優化有限，無法自動轉為 Semi-Join 或 Materialization。
• EXPLAIN 會顯示 DEPENDENT SUBQUERY，rows 接近外層表全量。

改寫策略與效果

驗證指標

• 優化前：12 次執行，最長 480s，掃描 90 萬列。
• 優化後：執行時間降至 0.5s 內，掃描列數 < 1000。

核心心法：大表關聯子查詢優先考慮 JOIN 或 物化表，配合適當索引，避開優化器「下推」陷阱。

1. 上一篇文章： MySQL SQL 優化實戰：誤導優化器的索引 — 刪除 dateline 索引消除 5000 條阻塞查詢
2. 下一篇文章： MySQL 預存程序與函數完整開發指南：語法、參數、流程控制、游標、異常處理實戰範例

MySQL 資料庫相關知識

MySQL 客戶端啟動參數十大必知選項實戰指南

前言 MySQL 客戶端 mysql 擁有豐富的啟動選項，善

MySQL 查詢結果匯出 Excel 完整指南：常見錯誤與解決方案

方法一：單行指令直接匯出 在終端機（Windows CMD

MySQL入門系列：MySQL 中的 SQL 特性與擴充功能

SQL 在 MySQL 中的角色 無論使用 mysql 客戶

MyEclipse 連接 MySQL 失敗常見原因與解決方案

MyEclipse 連 MySQL 失敗通常歸結為兩類：ID