在大資料情況下MySQL的一種簡單分頁最佳化方法

cnnbull發表於2021-09-09

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

?

12345678910111213141516171819202122232425 root@sns 07:16:25>select count(*) from reply_0004 where thread_id = 5616385 and deleted = 0;+———-+| count(*) |+———-+| 1236795 |+———-+1 row in set (0.44 sec)root@sns 07:16:30>select idfrom reply_0004 where thread_id = 5616385 and deleted = 0order 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的方式來實現翻頁,這樣就可以較好的提高效能:

?

1234567891011121314151617181920212223242526272829303132333435 root@snsgroup 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%以上。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/2524/viewspace-2805478/,如需轉載,請註明出處,否則將追究法律責任。

相關文章