目前在進行web api唯讀介面的改造，在改造過程中，發現改在後響應時間和之前區別不是很大，通過測試結果顯示在sql的分頁功能處找到原因，並對其進行優化，優化方案如下。
測試內容
此次執行時間對比採用平台資金記錄最多的使用者 user_id 36062
測試次數未5次 為避免索引快取每次測試前更改 limit 的起始值，查詢條數10不變。
5次結果取平均值優化前平均查詢時間為
0.287s
優化後sql1
平均查詢時間為
0.012s
優化後sql2
平均查詢時間為
0.016s
結果顯示：優化後的sql1和sql2查詢效率明顯高於優化前。
通過先查找到所有滿足條件的索引，然後通過索引檢索到所需要的資料，效率提高很多。
附：sql
原sql
select * from account_log where user_id = 36062order by id desc limit 3300, 10;
優化後的
sql 1
select * from account_log a join ( selectid from rd_account_log where user_id = 36062 order by id desc limit 3300, 10) bon b.id = a.id;
優化有sql 2
select * from account_log where user_id =36062 and id <=(select id from rd_account_log
where user_id = 36062 order by id desc limit33416,1) limit 10
總結1、隨著起始記錄的增加，時間也隨著增大， 這說明分頁語句limit跟起始頁碼是有很大關係的；
1）limit語句的查詢時間與起始記錄的位置成正比
2）mysql的limit語句是很方便，但是對記錄很多的表並不適合直接使用。
2、利用表的覆蓋索引來加速分頁查詢
我們都知道，利用了索引查詢的語句中如果只包含了那個索引列（覆蓋索引），那麼這種情況會查詢很快。
因為利用索引查詢有優化演算法，且資料就在查詢索引上面，不用再去找相關的資料位址了，這樣節省了很多時間。另外mysql中也有相關的索引快取，在併發高的時候利用快取就效果更好了。
MySQL大資料量分頁效能優化
mysql大資料量使用limit分頁，隨著頁碼的增大，查詢效率越低下。1.直接用limit start,count分頁語句，也是我程式中用的方法 select from product limit start,count 當起始頁較小時，查詢沒有效能問題，我們分別看下從10，100，1000，100...
MySQL大資料量分頁效能優化
1.直接用limit start,count分頁語句，也是我程式中用的方法 select from product limit start,count 當起始頁較小時，查詢沒有效能問題，我們分別看下從10，100，1000，10000開始分頁的執行時間 每頁取20條 如下 select from p...
大資料量分頁優化
用limit offset 時並不是先跳過再查詢 而是 先查詢,再跳過 limit 100w,10 先把100w取出來,然後跳過前100w行,所以大資料分頁用limit很慢 select id,name from lx com 5000000,10 先查詢出來5000000 select id,na...