SELECT * FROM t WHERE condition ORDER BY col LIMIT 1000000, 20;
Using filesort + Using temporary 擴大開銷
-- 1. 只走索引取主鍵
SELECT id FROM t WHERE condition ORDER BY col LIMIT 1000000, 20;
-- 2. 回表取完整列
SELECT t.* FROM t
INNER JOIN (
SELECT id FROM t WHERE condition ORDER BY col LIMIT 1000000, 20
) tmp USING (id);
Using index），極窄行、極快WHERE + ORDER BY 的場景
-- 首頁
SELECT * FROM t WHERE condition ORDER BY id LIMIT 20;
-- 記住最後一行 id = 999999
-- 下一頁
SELECT * FROM t WHERE condition AND id > 999999 ORDER BY id LIMIT 20;
ORDER BY 欄位唯一且單調（主鍵/唯一索引）針對複雜搜索（全文、多條件組合），首次查詢將所有符合條件 id 存入 Redis/Session，分頁時直接 IN (id列表) 切片。
-- 首次搜索
SELECT id FROM t WHERE complex_condition ORDER BY relevance;
-- 存入 Redis: SET search:token:abc "id1,id2,id3..." EX 1800
-- 分頁請求
SELECT * FROM t WHERE id IN (取第 N 頁對應的 20 個 id) ORDER BY FIELD(id, ...);
定時任務預計算熱門查詢結果存入汇總表，分頁直接查汇總表。
SQL_CALC_FOUND_ROWS + FOUND_ROWS() 獲取總數：5.7+ 棄用，8.0 移除，改用單獨 COUNT(*)（可走覆蓋索引）。LIMIT 1000000, 20 配合 ORDER BY 無索引：必然全表掃描+排序，無解，必須加索引或改架構。COUNT(*) 結果緩存 5-15 分鐘，接受近似總數。OFFSET 過大：前端限制最大頁碼（如 1000 頁），超過引導用戶用搜索/篩選縮小範圍。分頁優化核心：**減少掃描行數、利用索引順序、避免物化大結果集**。游標分頁 > 延遲關聯 > 應用緩存 > 物化視圖，按業務場景組合使用。深分頁本質是「需求與模型不匹配」，極致優化往往在架構層面（引入 Elasticsearch、預計算、CQRS）。
