通常應用需要對錶中的資料進行翻頁，如果資料量很大，往往會帶來效能上的問題：

[email protected] 07:16:25>select count(*) from  reply_0004 where thread_id = 5616385 and deleted = 0; +———-+ | count(*) | +———-+ |  1236795 | +———-+ 1 row in set (0.44 sec) [email protected] 07:16:30>select id from reply_0004 where thread_id = 5616385 and deleted = 0 order by id asc limit 1236785, 10 ; +———–+ | id        | +———–+ | 162436798 | | 162438180 | | 162440102 | | 162442044 | | 162479222 | | 162479598 | | 162514705 | | 162832588 | | 162863394 | | 162899685 | +———–+ 10 rows in set (1.32 sec) 索引：threa_id+deleted+id（gmt_Create） 10 rows in set (1.32 sec) 這兩條sql是為查詢最後一頁的翻頁sql查詢用的。由於一次翻頁往往只需要查詢較小的資料，如10條，但需要向後掃描大量的資料，也就是越往後的翻頁查詢，掃描的資料量會越多，查詢的速度也就越來越慢。 由於查詢的資料量大小是固定的，如果查詢速度不受翻頁的頁數影響，或者影響最低，那麼這樣是最佳的效果了（查詢最後最幾頁的速度和開始幾頁的速度一致）。 在翻頁的時候，往往需要對其中的某個欄位做排序（這個欄位在索引中），升序排序。那麼可不可以利用索引的有序性來解決上面遇到的問題喃，答案是肯定的。比如有10000條資料需要做分頁，那麼前5000條做asc排序，後5000條desc排序，在limit startnum，pagesize引數中作出相應的調整。 但是這無疑給應用程式帶來複雜，這條sql是用於論壇回覆帖子的sql，往往使用者在看帖子的時候，一般都是檢視前幾頁和最後幾頁，那麼在翻頁的時候最後幾頁的翻頁查詢採用desc的方式來實現翻頁，這樣就可以較好的提高效能：

[email protected] 07:16:49>select * from (select id

->            from group_thread_reply_0004 where thread_id = 5616385 and deleted = 0

->        order by id desc limit 0, 10)t order by t.id asc;

+———–+

| id        |

+———–+

| 162436798 |

| 162438180 |

| 162440102 |

| 162442044 |

| 162479222 |

| 162479598 |

| 162514705 |

| 162832588 |

| 162863394 |

| 162899685 |

+———–+

10 rows in set (0.87 sec)

可以看到效能提升了50%以上。