# 分頁技巧
## 傳統分頁
select * from table limit 10000,10;
* LIMIT的坑
偏移量越大則越慢
例如 limit 10000,10，則至少需要先掃描前面的10000條記錄，然后再往后位移10條記錄，效率很差。
## 下面我們演示了幾種分頁SQL改進方案。
* 分頁SQL改進方案一： 利用主鍵條件，跳過前面N條記錄掃描
```
select * from table WHERE id>=23423 limit 11; #10+1 (每頁10條)
select * from table WHERE id>=23434 limit 11;
```
* 改進方案二：利用子查詢優化
```
Select * from table WHERE id >= ( select id from table limit 10000,1 ) limit 10;
```
* 改進方案三：利用JOIN優化
```
SELECT * FROM table INNER JOIN (SELECT id FROM table LIMIT 10000,10) USING (id) ;
```
* 改進方案四：直接利用主鍵ID進行取值（其實和方案二、三類似）
```
程序中先取的主鍵ID值：select id from table limit 10000,10;
再把這些值傳遞到IN子句中：select * from table WHERE id in (123,456…) ;
```
## LIMIT分頁舉例
```
MySQL> select sql_no_cache * from post limit 10,10;
10 row in set (0.01 sec)
MySQL> select sql_no_cache * from post limit 20000,10;
10 row in set (0.13 sec)
MySQL> select sql_no_cache * from post limit 80000,10;
10 rows in set (0.58 sec)
```
**隨著LIMIT中OFFSET值的增加，SQL耗時也明顯增加**
```
MySQL> select sql_no_cache * from post WHERE id>=323423 limit 10;
10 rows in set (0.01 sec)
```
**利用主鍵ID先進行條件判斷，效率提升很高**
```
MySQL> select * from post WHERE id >= ( select sql_no_cache id from post limit 80000,1 ) limit 10 ;
10 rows in set (0.02 sec)
```
**改成子查詢方案，效率耶不錯**
分頁的業務邏輯改進
## Limit分頁與緩存結合
類似sina微博的首頁，只推薦 最新的500條微博記錄，最多10頁
分頁樣式類似如下：
并且在邏輯中限死，這樣就不會出現分頁邏輯被爬蟲爬死的問題了。
