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
查詢時間也很短，贊！
其實兩者用的都是乙個原理嘛，所以效果也差不多
MySQL大資料量分頁效能優化
mysql大資料量使用limit分頁，隨著頁碼的增大，查詢效率越低下。1.直接用limit start,count分頁語句，也是我程式中用的方法 select from product limit start,count 當起始頁較小時，查詢沒有效能問題，我們分別看下從10，100，1000，100...
Mysql大資料量分頁優化
假設有乙個千萬量級的表，取1到10條資料 select from table limit 0,10 select from table limit 1000,10 這兩條語句查詢時間應該在毫秒級完成 select from table limit 3000000,10 你可能沒想到，這條語句執行之間...
SQL大資料量分頁效能優化
目前在進行web api唯讀介面的改造，在改造過程中，發現改在後響應時間和之前區別不是很大，通過測試結果顯示在sql的分頁功能處找到原因，並對其進行優化，優化方案如下。測試內容 此次執行時間對比採用平台資金記錄最多的使用者 user id 36062 測試次數未5次 為避免索引快取每次測試前更改 l...