快捷導(dǎo)航

在大數(shù)據(jù)情況下MySQL的一種簡(jiǎn)單分頁(yè)優(yōu)化方法

更新時(shí)間：2015年05月08日 10:13:27 作者：羅龍九

這篇文章主要介紹了在大數(shù)據(jù)情況下MySQL的一種簡(jiǎn)單分頁(yè)優(yōu)化方法,分頁(yè)優(yōu)化是MySQL優(yōu)化的常用手段之一,需要的朋友可以參考下

通常應(yīng)用需要對(duì)表中的數(shù)據(jù)進(jìn)行翻頁(yè)，如果數(shù)據(jù)量很大，往往會(huì)帶來(lái)性能上的問(wèn)題：

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 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是為查詢(xún)最后一頁(yè)的翻頁(yè)sql查詢(xún)用的。由于一次翻頁(yè)往往只需要查詢(xún)較小的數(shù)據(jù)，如10條，但需要向后掃描大量的數(shù)據(jù)，也就是越往后的翻頁(yè)查詢(xún)，掃描的數(shù)據(jù)量會(huì)越多，查詢(xún)的速度也就越來(lái)越慢。
由于查詢(xún)的數(shù)據(jù)量大小是固定的，如果查詢(xún)速度不受翻頁(yè)的頁(yè)數(shù)影響，或者影響最低，那么這樣是最佳的效果了（查詢(xún)最后最幾頁(yè)的速度和開(kāi)始幾頁(yè)的速度一致）。
在翻頁(yè)的時(shí)候，往往需要對(duì)其中的某個(gè)字段做排序（這個(gè)字段在索引中），升序排序。那么可不可以利用索引的有序性來(lái)解決上面遇到的問(wèn)題喃，答案是肯定的。比如有10000條數(shù)據(jù)需要做分頁(yè)，那么前5000條做asc排序，后5000條desc排序，在limit startnum，pagesize參數(shù)中作出相應(yīng)的調(diào)整。
但是這無(wú)疑給應(yīng)用程序帶來(lái)復(fù)雜，這條sql是用于論壇回復(fù)帖子的sql，往往用戶(hù)在看帖子的時(shí)候，一般都是查看前幾頁(yè)和最后幾頁(yè)，那么在翻頁(yè)的時(shí)候最后幾頁(yè)的翻頁(yè)查詢(xún)采用desc的方式來(lái)實(shí)現(xiàn)翻頁(yè)，這樣就可以較好的提高性能：

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%以上。

您可能感興趣的文章: