起因
需求：獲取某用戶的所有操作記錄日志
日志數量雖然不多，但不可能一股腦的塞給用戶，難看不說，還拖累服務器性能，因而分頁必不可少
limit
基礎用法
limit 的用法是 limit [offset], [rows]，其中 offset 表示偏移值， rows 表示需要返回的數據行。
問題
mysql 的 limit 給分頁帶來了極大的方便，但數據偏移量一大，limit 的性能就急劇下降。
以下是兩條查詢語句，都是取10條數據，但性能就相去甚遠
select * from table_name limit 10000,10 select * from table_name limit 0,10
所以不能簡單的使用 limit 語句實現數據分頁。
探究
為什么 offset 偏大之后 limit 查找會變慢？這需要了解 limit 操作是如何運作的，以下面這句查詢為例：
select * from table_name limit 10000,10
這句 SQL 的執行邏輯是
1.從數據表中讀取第N條數據添加到數據集中
2.重復第一步直到 N = 10000 + 10
3.根據 offset 拋棄前面 10000 條數
4.返回剩余的 10 條數據
顯然，導致這句 SQL 速度慢的問題出現在第二步！這前面的 10000 條數據完全對本次查詢沒有意義，但是卻占據了絕大部分的查詢時間！如何解決？首先我們得了解為什么數據庫為什么會這樣查詢。
首先，數據庫的數據存儲並不是像我們想象中那樣，按表按順序存儲數據，一方面是因為計算機存儲本身就是隨機讀寫，另一方面是因為數據的操作有很大的隨機性，即使一開始數據的存儲是有序的，經過一系列的增刪查改之后也會變得凌亂不堪。所以數據庫的數據存儲是隨機的，使用 B+Tree， Hash 等方式組織索引。所以當你讓數據庫讀取第 10001 條數據的時候，數據庫就只能一條一條的去查去數。
第一次優化
根據數據庫這種查找的特性，就有了一種想當然的方法，利用自增索引（假設為id）：
select * from table_name where (id >= 10000) limit 10由於普通搜索是全表搜索，適當的添加 WHERE 條件就能把搜索從全表搜索轉化為范圍搜索，大大縮小搜索的范圍，從而提高搜索效率。
這個優化思路就是告訴數據庫：「你別數了，我告訴你，第10001條數據是這樣的，你直接去拿吧。」
但是！！！你可能已經注意到了，這個查詢太簡單了，沒有任何的附加查詢條件，如果我需要一些額外的查詢條件，比如我只要某個用戶的數據 ，這種方法就行不通了。
可以見到這種思路是有局限性的，首先必須要有自增索引列，而且數據在邏輯上必須是連續的，其次，你還必須知道特征值。
如此苛刻的要求，在實際應用中是不可能滿足的。
第二次優化
說起數據庫查詢優化，第一時間想到的就是索引，所以便有了第二次優化：先查找出需要數據的索引列（假設為 id），再通過索引列查找出需要的數據。
Select * From table_name Where id in (Select id From table_name where ( user = xxx )) limit 10000, 10; select * from table_name where( user = xxx ) limit 10000,10相比較結果是（500w條數據）：第一條花費平均耗時約為第二條的 1/3 左右。
同樣是較大的 offset，第一條的查詢更為復雜，為什么性能反而得到了提升？
這涉及到 mysql 主索引的數據結構 b+Tree ，這里不展開，基本原理就是：
- 子查詢只用到了索引列，沒有取實際的數據，所以不涉及到磁盤IO，所以即使是比較大的 offset 查詢速度也不會太差。
- 利用子查詢的方式，把原來的基於 user 的搜索轉化為基於主鍵（id）的搜索，主查詢因為已經獲得了准確的索引值，所以查詢過程也相對較快。
第三次優化
在數據量大的時候 in 操作的效率就不怎么樣了，我們需要把 in 操作替換掉，使用 join 就是一個不錯的選擇。
select * from table_name inner join ( select id from table_name where (user = xxx) limit 10000,10) b using (id) 至此 limit 在查詢上的優化就告一段落了。如果還有更好的優化方式，歡迎留言告知
最終優化
技術上的優化始終是有天花板的，業務的優化效果往往更為顯著。