目前在進行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中也有相關的索引快取，在併發高的時候利用快取就效果更好了。