在 MySQL 中，limit X,Y 的查詢中，X 值越大，那么查詢速度也就越慢，例如以下示例：

• limit 0,10：查詢時間大概在 20 毫秒左右。
• limit 1000000,10：查詢時間可能是 15 秒左右（1秒等于 1000 毫秒），甚至更長時間。

所以，可以看出，limit 中 X 值越大，那么查詢速度都越慢。

這個問題呢其實就是 MySQL 中典型的深度分頁問題。那問題來了，為什么 limit 越往后查詢越慢？如何優(yōu)化查詢速度呢？

為什么limit越來越慢？

在數(shù)據(jù)庫查詢中，當(dāng)使用 LIMIT x, y 分頁查詢時，如果 x 值越大，查詢速度可能會變慢。這主要是因為數(shù)據(jù)庫需要掃描和跳過 x 條記錄才能返回 y 條結(jié)果。隨著 x 的增加，需要掃描和跳過的記錄數(shù)也增加，從而導(dǎo)致性能下降。

例如 limit 1000000,10 需要掃描 1000010 行數(shù)據(jù)，然后丟掉前面的 1000000 行記錄，所以查詢速度就會很慢。

優(yōu)化手段

對于 MySQL 深度分頁比較典型的優(yōu)化手段有以下兩種：

• 起始 ID 定位法：使用最后查詢的 ID 作為起始查詢的 ID。
• 索引覆蓋+子查詢。

1.起始ID定位法

起始 ID 定位法指的是 limit 查詢時，指定起始 ID。而這個起始 ID 是上一次查詢的最后一條 ID。例如上一次查詢的最后一條數(shù)據(jù)的 ID 為 6800000，那我們就從 6800001 開始掃描表，直接跳過前面的 6800000 條數(shù)據(jù)，這樣查詢的效率就高了，具體實現(xiàn) SQL 如下：

select name, age, gender
from person
where id > 6800000 -- 核心實現(xiàn) SQL
order by id limit 10;

其中 id 字段為表的主鍵字段。

為什么起始ID查詢效率高呢？

因此這種查詢是以上一次查詢的最后 ID 作為起始 ID 進行查詢的，而上次的 ID 已經(jīng)定位到具體的位置了，所以只需要遍歷 B+ 樹葉子節(jié)點的雙向鏈表（主鍵索引的底層數(shù)據(jù)結(jié)構(gòu)）就可以查詢到后面的數(shù)據(jù)了，所以查詢效率就比較高，如下圖所示：

如果上次查詢結(jié)果為 9，之后再查詢時，只需要從 9 之后再遍歷 N 條數(shù)據(jù)就能查詢出結(jié)果了，所以效率就很高。

優(yōu)缺點分析

這種查詢方式，只適合一頁一頁的數(shù)據(jù)查詢，例如手機 APP 中刷新聞時那種瀑布流方式。

但如果用戶是跳著分頁的，例如查詢完第 1 頁之后，直接查詢第 250 頁，那么這種實現(xiàn)方式就不行了。

2.索引覆蓋+子查詢

此時我們?yōu)榱瞬樵冃剩梢允褂盟饕采w加子查詢的方式，具體實現(xiàn)如下。

假設(shè)，我們未優(yōu)化前的 SQL 如下：

select name, age, gender
from person
order by createtime desc 
limit 1000000,10;

在以上 SQL 中，createtime 字段創(chuàng)建了索引，但查詢效率依然很慢，因為它要取出 100w 完整的數(shù)據(jù)，并需要讀取大量的索引頁，和進行頻繁的回表查詢，所以執(zhí)行效率會很低。

此時，我們可以做以下優(yōu)化：

SELECT p1.name, p1.age, p1.gender
FROM person p1
JOIN (
    SELECT id FROM person ORDER BY createtime desc LIMIT 1000000, 10
) AS p2 ON p1.id = p2.id;

相比于優(yōu)化前的 SQL，優(yōu)化后的 SQL 將不需要頻繁回表查詢了，因為子查詢中只查詢主鍵 ID，這時可以使用索引覆蓋來實現(xiàn)。那么子查詢就可以先查詢出一小部分主鍵 ID，再進行查詢，這樣就可以大大提升查詢的效率了。

索引覆蓋（Index Coverage）是一種數(shù)據(jù)庫查詢優(yōu)化技術(shù)，它指的是在執(zhí)行查詢時，數(shù)據(jù)庫引擎可以直接從索引中獲取所有需要的數(shù)據(jù)，而不需要再回表（訪問主鍵索引或者表中的實際數(shù)據(jù)行）來獲取額外的信息。這種方式可以減少磁盤 I/O 操作，從而提高查詢性能。