LIMIT 100000, 10 這類深分頁隨著偏移量增大效能急劇下降（需掃描並捨棄前 10 萬行）。本文實戰展示「子查詢定位起始 ID + 索引範圍掃描」優化方案，效能提升數十倍。

問題現場

• Sitemap 生成需全表掃描 8 萬+ 文章 ID
• SELECT aid FROM articles ORDER BY aid LIMIT 80000, 4000 極慢

優化前後對比

-- 原始：掃描 8 萬行再取 4000 行
SELECT aid FROM articles ORDER BY aid LIMIT 80000, 4000;

-- 優化：子查詢先定位起始 ID，再索引範圍掃描
SELECT aid FROM articles
WHERE aid >= (SELECT aid FROM articles ORDER BY aid LIMIT 80000, 1)
ORDER BY aid LIMIT 4000;

原理解析

1. 子查詢 LIMIT 80000, 1 僅需走索引取 1 個 ID，極快
2. 外層 WHERE aid >= 起始值 直接利用主鍵索引範圍掃描，跳過前 8 萬行
3. 避免了「掃描+捨棄」的巨大開銷

進階：JOIN 寫法（同樣高效）

SELECT id, login_name, password
FROM user
JOIN (SELECT id FROM user ORDER BY login_name LIMIT 200000, 10) AS u2 USING(id);

EXPLAIN 顯示：Derived table (using index) + Primary key lookup，三階段極速。

綜合建議

• 淺分頁（< 1 萬）：直接 LIMIT 即可
• 深分頁：子查詢定位起始值 + 索引範圍掃描
• 極大偏移：考慮游標分頁（記錄上次最大 ID）或覆蓋索引優化