測試實驗
1. 直接用limit start, count分頁語句， 也是我程式中用的方法：
select * from product limit start, count
當起始頁較小時，查詢沒有效能問題，我們分別看下從10， 100， 1000， 10000開始分頁的執行時間(每頁取20條)， 如下：
select * from product limit 10, 20 0.016秒select * from product limit 100, 20 0.016秒select * from product limit 1000, 20 0.047秒select * from product limit 10000, 20 0.094秒
我們已經看出隨著起始記錄的增加，時間也隨著增大， 這說明分頁語句limit跟起始頁碼是有很大關係的，那麼我們把起始記錄改為40w看下(也就是記錄的一般左右)
select * from product limit 400000, 20 3.229秒
再看我們取最後一頁記錄的時間
select * from product limit 866613, 20 37.44秒
難怪搜尋引擎抓取我們頁面的時候經常會報超時，像這種分頁最大的頁碼頁顯然這種時間是無法忍受的。
從中我們也能總結出兩件事情：
1)limit語句的查詢時間與起始記錄的位置成正比
2)mysql的limit語句是很方便，但是對記錄很多的表並不適合直接使用。
2. 對limit分頁問題的效能優化方法
利用表的覆蓋索引來加速分頁查詢
我們都知道，利用了索引查詢的語句中如果只包含了那個索引列(覆蓋索引)，那麼這種情況會查詢很快。
在我們的例子中，我們知道id欄位是主鍵，自然就包含了預設的主鍵索引。現在讓我們看看利用覆蓋索引的查詢效果如何：
這次我們之間查詢最後一頁的資料(利用覆蓋索引，只包含id列)，如下：
select id from product limit 866613, 20 0.2秒
相對於查詢了所有列的37.44秒，提公升了大概100多倍的速度
那麼如果我們也要查詢所有列，有兩種方法，一種是id>=的形式，另一種就是利用join，看下實際情況：
select * from product where id > =(select id from product limit 866613, 1) limit 20
查詢時間為0.2秒，簡直是乙個質的飛躍啊，哈哈
另一種寫法
select * from product a join (select id from product limit 866613, 20) b on a.id = b.id
查詢時間也很短，贊！
其實兩者用的都是乙個原理，所以效果也差不多，核心思想就是將分頁的壓力放在id上，而id有唯一索引，可以將分頁帶來的效率問題降到最低。不過第一種要求id連續遞增的，如果你的id使用的是uuid則無法滿足，第二種相對來說使用範圍更廣，推薦使用！
mysql 分頁優化 Mysql 查詢分頁優化
全表掃瞄，速度極慢 limit 語句的查詢時間與起始記錄的位置成正比 mysql 的 limit 語句是很方便，但是對記錄很多的表並不適合直接使用 建立測試表 drop table if exists t user create table test t user id int 10 unsigne...
MySQL如何優化分頁查詢
mysql如何優化分頁查詢一般分頁查詢是建立覆蓋索引能夠比較好的提公升效能。第一種優化思路 在索引上完成分頁操作，最後根據主鍵關聯回原表查詢所需要的其他列內容 未優化之前的sql,這個相當於是全表掃瞄 select film id,description from film order by tit...
Mysql 分頁查詢優化
分頁查詢優化 分頁查詢在 mysql 中常遇到，如以下語句 select from tablename limit 100,20 用時大約需要0.03 sec。用時很短。但是隨著偏移量的增加，查詢時間也隨之增加。比如如下 select from tablename limit 10000000,20...