共計 1749 個字符，預計需要花費 5 分鐘才能閱讀完成。
自動寫代碼機器人，免費開通
今天就跟大家聊聊有關 MySQL 中怎么優化分頁查詢，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
分頁查詢方法：
在 MySQL 中，分頁查詢一般都是使用 limit 子句實現，limit 子句聲明如下：
LIMIT 子句可以被用于指定 SELECT 語句返回的記錄數。需注意以下幾點：
1、第一個參數指定第一個返回記錄行的偏移量
2、第二個參數指定返回記錄行的最大數目
3、如果只給定一個參數：它表示返回最大的記錄行數目
4、第二個參數為 -1 表示檢索從某一個偏移量到記錄集的結束所有的記錄行
5、初始記錄行的偏移量是 0(而不是 1)
下面是一個應用實例：
該條語句將會從表 orders_history 中查詢第 1000 條數據之后的 10 條數據，也就是第 1001 條到第 1010 條數據。
數據表中的記錄默認使用主鍵 (一般為 id) 排序，上面的結果相當于：
三次查詢時間分別為：
3040 ms
3063 ms
3018 ms
針對這種查詢方式，下面測試查詢記錄量對時間的影響：
三次查詢時間如下：
查詢 1 條記錄：3072ms 3092ms 3002ms
查詢 10 條記錄：3081ms 3077ms 3032ms
查詢 100 條記錄：3118ms 3200ms 3128ms
查詢 1000 條記錄：3412ms 3468ms 3394ms
查詢 10000 條記錄：3749ms 3802ms 3696ms
另外我還做了十來次查詢，從查詢時間來看，基本可以確定，在查詢記錄量低于 100 時，查詢時間基本沒有差距，隨著查詢記錄量越來越大，所花費的時間也會越來越多。
針對查詢偏移量的測試：
三次查詢時間如下：
查詢 100 偏移：25ms 24ms 24ms
查詢 1000 偏移：78ms 76ms 77ms
查詢 10000 偏移：3092ms 3212ms 3128ms
查詢 100000 偏移：3878ms 3812ms 3798ms
查詢 1000000 偏移：14608ms 14062ms 14700ms
隨著查詢偏移的增大，尤其查詢偏移大于 10 萬以后，查詢時間急劇增加。
這種分頁查詢方式會從數據庫第一條記錄開始掃描，所以越往后，查詢速度越慢，而且查詢的數據越多，也會拖慢總查詢速度。
使用子查詢優化
這種方式先定位偏移位置的 id，然后往后查詢，這種方式適用于 id 遞增的情況。
4 條語句的查詢時間如下：
第 1 條語句：3674ms
第 2 條語句：1315ms
第 3 條語句：1327ms
第 4 條語句：3710ms
針對上面的查詢需要注意：
1、比較第 1 條語句和第 2 條語句：使用 select id 代替 select * 速度增加了 3 倍
2、比較第 2 條語句和第 3 條語句：速度相差幾十毫秒
3、比較第 3 條語句和第 4 條語句：得益于 select id 速度增加，第 3 條語句查詢速度增加了 3 倍
這種方式相較于原始一般的查詢方法，將會增快數倍。
使用 id 限定優化
這種方式假設數據表的 id 是連續遞增的，則我們根據查詢的頁數和查詢的記錄數可以算出查詢的 id 的范圍，可以使用 id between and 來查詢：
查詢時間：15ms 12ms 9ms
這種查詢方式能夠極大地優化查詢速度，基本能夠在幾十毫秒之內完成。限制是只能使用于明確知道 id 的情況，不過一般建立表的時候，都會添加基本的 id 字段，這為分頁查詢帶來很多便利。
還可以有另外一種寫法：
當然還可以使用 in 的方式來進行查詢，這種方式經常用在多表關聯的時候進行查詢，使用其他表查詢的 id 集合，來進行查詢：
這種 in 查詢的方式要注意：某些 mysql 版本不支持在 in 子句中使用 limit。
關于數據表的 id 說明
一般情況下，在數據庫中建立表的時候，每一張表強制添加 id 遞增字段，這樣更方便我們查詢數據。
如果數據量很大，比如像訂單這類，一般會推薦進行分庫分表。這個時候 id 就不建議作為唯一標識了，而應該使用分布式的高并發唯一 id 生成器來生成，并在數據表中使用另外的字段來存儲這個唯一標識。
首先使用范圍查詢定位 id (或者索引)，然后再使用索引進行定位數據，即先 select id，然后在 select *; 這樣查詢的速度將會提升好幾倍。
看完上述內容，你們對 MySQL 中怎么優化分頁查詢有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
向 AI 問一下細節
