一、MySQL分頁為什么會慢常見分頁SELECT * FROM orders ORDER BY id LIMIT 1000000, 20;LIMIT offset, size表示跳過前offset條再返回size條。上面的 SQL 不是直接跳到第 1000001 條而是需要沿著結(jié)果順序讀取大量記錄跳過前 100 萬條只返回最后 20 條。頁碼越深需要檢查并丟棄的記錄越多?？梢院唵卫斫鉃長IMIT 0, 20 檢查約20條 LIMIT 1000, 20 檢查約1020條 LIMIT 1000000, 20 檢查約1000020條因此傳統(tǒng)分頁的成本通常隨著offset增大而增長。二、分頁的主要性能問題1. 深分頁掃描大量無用記錄SELECT * FROM orders ORDER BY id LIMIT 1000000, 20;真正返回20條但前面100萬條都屬于無效工作帶來更多BTree葉子節(jié)點(diǎn)遍歷Buffer Pool訪問CPU條件判斷磁盤I/O可能的回表查詢。2. 二級索引排序可能產(chǎn)生大量回表假設(shè)有索引CREATE INDEX idx_created_at ON orders(created_at);查詢SELECT * FROM orders ORDER BY created_at LIMIT 1000000, 20;二級索引葉子節(jié)點(diǎn)主要保存(created_at, 主鍵id)但SELECT *需要完整記錄所以可能通過主鍵到聚簇索引查詢數(shù)據(jù)。InnoDB二級索引記錄包含主鍵完整行數(shù)據(jù)則存放在聚簇索引中。深分頁情況下可能出現(xiàn)掃描大量二級索引記錄 ↓ 通過主鍵回表 ↓ 丟棄前面的記錄 ↓ 只返回20條具體是否以及何時回表由執(zhí)行計劃決定。3. 排序不能使用索引時出現(xiàn)filesortSELECT * FROM orders WHERE status 1 ORDER BY amount LIMIT 100000, 20;如果沒有合適索引MySQL可能先找出符合條件的記錄再進(jìn)行filesort。即使最終只返回20條也可能需要讀取和處理大量候選記錄?？梢酝ㄟ^EXPLAIN的Extra是否出現(xiàn)Using filesort判斷。4. 分頁結(jié)果可能不穩(wěn)定不寫ORDER BYSELECT * FROM orders LIMIT 20, 20;數(shù)據(jù)庫不保證每次返回順序一致。即使寫了ORDER BY created_at如果多條記錄的created_at相同它們之間的順序仍不確定應(yīng)增加唯一字段ORDER BY created_at DESC, id DESCMySQL官方文檔也建議增加額外排序列使順序具有確定性。三、優(yōu)化一建立匹配條件和排序的聯(lián)合索引查詢SELECT id, user_id, status, created_at FROM orders WHERE user_id 100 AND status 1 ORDER BY created_at DESC, id DESC LIMIT 20;建立索引CREATE INDEX idx_user_status_time_id ON orders(user_id, status, created_at DESC, id DESC);索引順序可以理解為等值查詢列 → 排序列 → 唯一排序列 user_id, status, created_at, id這樣MySQL可以先定位用戶和狀態(tài)再按照索引順序讀取減少掃描和額外排序。MySQL能夠在索引順序滿足ORDER BY時避免filesort但要注意索引能夠減少排序和過濾成本卻不能從根本上解決巨大offset帶來的跳過成本。四、優(yōu)化二游標(biāo)分頁最推薦也叫Keyset PaginationSeek Pagination基于最后一條記錄分頁第一頁SELECT * FROM orders WHERE user_id 100 AND status 1 ORDER BY created_at DESC, id DESC LIMIT 20;記錄最后一條數(shù)據(jù)created_at 2026-08-01 10:00:00 id 5000下一頁SELECT * FROM orders WHERE user_id 100 AND status 1 AND ( created_at 2026-08-01 10:00:00 OR (created_at 2026-08-01 10:00:00 AND id 5000) ) ORDER BY created_at DESC, id DESC LIMIT 20;配合索引CREATE INDEX idx_user_status_time_id ON orders(user_id, status, created_at DESC, id DESC);執(zhí)行過程變成從上一頁最后位置附近定位 ↓ 繼續(xù)讀取20條優(yōu)點(diǎn)深度增加時性能比較穩(wěn)定不需要跳過前面幾十萬條數(shù)據(jù)新增時不容易出現(xiàn)重復(fù)數(shù)據(jù)特別適合信息流、訂單列表和滾動加載缺點(diǎn)不能方便地直接跳到第10000頁前端需要保存上一頁最后一條記錄的游標(biāo)排序字段最好穩(wěn)定且不允許為NULL最好加入唯一字段id避免游標(biāo)位置不唯一五、優(yōu)化三延遲關(guān)聯(lián)如果業(yè)務(wù)必須使用頁碼和大offset可以先使用覆蓋索引找到20個主鍵再查詢完整數(shù)據(jù)SELECT o.* FROM orders AS o JOIN ( SELECT id FROM orders WHERE status 1 ORDER BY created_at DESC, id DESC LIMIT 1000000, 20 ) AS p ON p.id o.id ORDER BY o.created_at DESC, o.id DESC;配合索引CREATE INDEX idx_status_time_id ON orders(status, created_at DESC, id DESC);內(nèi)部查詢只讀取索引中的小字段掃描覆蓋索引 → 獲得20個id → 只回表20次它減少了大量無意義的回表但仍然需要跳過100萬條索引記錄所以是緩解方案不是深分頁的根本解決方案