常見的幾種分頁方式：
1.扶梯方式
扶梯方式在技術實現上比較簡單及高效，根據當前頁最後一條的偏移往後獲取一頁即可。寫成sql可能類似
select*fromlist_tablewhereid> offset_id limit n;
1.電梯方式
另外一種資料獲取方式在產品上體現成精確的翻頁方式，如1,2,3……n，同時在導航上也可以由使用者輸入直達n頁。國內大部分場景採用電梯方式，但電梯方式在技術實現上相對成本較高。
在mysql中，通常提到的b-tree，在儲存引擎實現上，通常都是b+tree。
使用電梯方式時候，當使用者指定翻到第n頁時候，並沒有直接方法定址到該位置，而是需要從第一樓逐個count，scan到count*page時候，獲取資料才真正開始，所以導致效率不高。
傳統分頁技術(電梯方式)
首先前端需要傳給你的分頁實體，以及查詢條件
//分頁實體
structfinancedcpage{
1:i32 pagesize,//頁容量
2:i32 pageindex,//當前頁索引
然後你需要返回查詢總條數給前端；
selectcount(*)frommy_tablewherex= y orderbyid;
然後再返回指定頁麵條數給前端：
select*frommy_tablewherex= y orderbydate_collimit (pageindex - 1)* pagesize, pagesize;
由上面兩條sql語句查詢出來的結果需要返回給前端的分頁實體，以及單頁結果集
//分頁實體
structfinancedcpage{
1:i32 pagesize,//頁容量
2:i32 pageindex,//當前頁索引
3:i32 pagetotal,//總頁數
4:i32 totalrecod,//總條數
傳統查詢方法，每次請求變化的只有pageindex值，也就是limit offset,num的offset
如limit 0,10; limit 10,10; …. limit10000,10;
上面的變化會導致每次查詢所執行的時間會有偏差，offset值越大需要的時間越長，如limit10000,10 需要讀取10010個資料才能得到想要的10條資料。
優化方法
傳統方法中我們了解到，影響效率的關鍵是程式遍歷了許多不需要的資料，找到了關鍵點那麼就從這裡著手。
如果沒有必須使用電梯方式的時候，我們可以使用扶梯的方式，來提高效能。
但是大多數情況，電梯形式更能滿足使用者的需求，所以我們就需要另找方法來優化電梯形式。
基於傳統方式的優化
上面提到的優化方式，要麼難以滿足使用者的需求，要麼實現起來過於複雜，所以如果資料量不是特別大的時候，像百來萬條資料，其實根本沒有必要使用上面的優化方法。
傳統方法已經足夠用了，只不過傳統方法也可能需要優化的地方。例如：
orderby優化
select*frompa_dc_floworderbysubject_codedesclimit100000,5
這條語句中使用了orderby關鍵字，那麼對什麼進行排序又非常重要了，如果你是對自增id進行排序的話，那麼這條語句就不需要優化了，如果是索引甚至非索引的話，那就需要優化了。
首先你要保證它是索引，不然真的會很慢。然後如果他是索引，但是本身不像自增id那樣有序的話，那麼就要改寫成下面的語句。
select*frompa_dc_flowinnerjoin(selectidfrompa_dc_floworderbysubject_codedesclimit100000,5)aspa_dc_flow_idusing(id);
下面是對兩條sql的 explain
由圖中我們可以看出，第二個sql可以少掃面很多頁面。
其實這涉及到order by的優化問題，第一條sql中並沒有利用到subject_code索引。如果你改為select subject_code …則用到了索引。下面是對order by的優化。
order by後的字段，如果要走索引，須與where 條件裡的某欄位建立復合索引！！或者說orcerby後的字段如果要走索引排序，它要麼與where條件裡的字段建立復合索引【這裡建立復合索引的時候，需要注意復合索引的列順序為(where欄位，order by欄位)，這樣才能滿足最左列原則，原因可能是order by欄位並能算在where 查詢條件中！】，要麼它自身要在where條件裡被引用到！
表asubject_code為普通字段,上面建有索引,id是自增主鍵
select*fromaorderbysubject_code//用不上索引
selectidfromaorderbysubject_code//能用上索引
selectsubject_codefromaorderbysubject_code//能用上索引
select*fromawheresubject_code= xx orderbysubject_code//能用上索引
意思是說order by 要避免使用檔案系統排序，要麼把order by的字段出現在select後，要麼使用order by欄位出現在where 條件裡，要麼把order by欄位與where條件字段建立復合索引！
第二條sql就是巧妙的利用第二種方式利用上了索引。 select id from a order bysubject_code，這種方式
count優化
當資料量非常大時，其實可以輸出總數的大概資料，利用explain語句，他並沒有真正去執行sql，而是進行的估算。
總結
MySQL深翻頁 MySQL跳頁
以前我在mysql中分頁都是用的 limit 100000,20這樣的方式，我相信你也是吧，但是要提高效率，讓分頁的 效率更高一些，更快一些,那我們又該怎麼做呢?如下 mysql explain select from message order by id desc limit 10000,20 ...
mysql優化之mysql查詢效能排序分析
mysql 查詢效能排序，從左至右，效能由最差到最好 all index range ref eq ref const system null 1.all 全表掃瞄 例 select from user 2.index 索引全掃瞄 例 select id from user 3.range 索引範圍...
mysql效能優化 mysql效能優化
優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下，存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢，hash有利於精確查詢。btree用的更多一些。btree索引的常...