有這樣的一個(gè)需求：select count(distinct nick) from user_access_xx_xx;
這條sql用于統(tǒng)計(jì)用戶訪問的uv，由于單表的數(shù)據(jù)量在10G以上，即使在user_access_xx_xx上加上nick的索引，
通過查看執(zhí)行計(jì)劃，也為全索引掃描，sql在執(zhí)行的時(shí)候，會(huì)對(duì)整個(gè)服務(wù)器帶來抖動(dòng)；
root@db 09:00:12>select count(distinct nick) from user_access;+―――――――-+| count(distinct nick) |+―――――――-+| 806934 |+―――――――-+1 row in set (52.78 sec)
執(zhí)行一次sql需要花費(fèi)52.78s，已經(jīng)非常的慢了
現(xiàn)在需要換一種思路來解決該問題：
我們知道索引的值是按照索引字段升序的，比如我們對(duì)（nick，other_column）兩個(gè)字段做了索引，那么在索引中的則是按照nick，other_column的升序排列：
我們現(xiàn)在的sql：select count(distinct nick) from user_access;則是直接從nick1開始一條條掃描下來，直到掃描到最后一個(gè)nick_n,
那么中間過程會(huì)掃描很多重復(fù)的nick，如果我們能夠跳過中間重復(fù)的nick，則性能會(huì)優(yōu)化非常多（在oracle中，這種掃描技術(shù)為loose index scan，但在5.1的版本中，mysql中還不能直接支持這種優(yōu)化技術(shù)）：
所以需要通過改寫sql來達(dá)到偽loose index scan：
root@db 09:41:30>select count(*) from ( select distinct(nick) from user_access)t ;| count(*) |+―――-+| 806934 |1 row in set (5.81 sec)
Sql中先選出不同的nick，最后在外面套一層，就可以得到nick的distinct值總和；
最重要的是在子查詢中：select distinct(nick) 實(shí)現(xiàn)了上圖中的偽loose index scan，優(yōu)化器在這個(gè)時(shí)候的執(zhí)行計(jì)劃為Using index for group-by ，
需要注意的是mysql把distinct優(yōu)化為group by，它首先利用索引來分組，然后掃描索引，對(duì)需要的nick只掃描一次；
兩個(gè)sql的執(zhí)行計(jì)劃分別為：
優(yōu)化寫法：
root@db 09:41:10>explain select distinct(nick) from user_access-> ;+―-+――――-+――――――――――+――-+―――――+――――-| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+―-+――――-+――――――――――+――-+―――――+――――-| 1 | SIMPLE | user_access | range | NULL | ind_user_access_nick | 67 | NULL | 2124695 | Using index for group-by |+―-+――――-+――――――――――+――-+―――――+――――-
原始寫法：
root@db 09:42:55>explain select count(distinct nick) from user_access;+―-+――――-+――――――――――+――-+―――――+――――-| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+―-+――――-+――――――――――+――-+―――――+――――-| 1 | SIMPLE | user_access | index | NULL | ind_user_access | 177 | NULL | 19546123 | Using index |
新聞熱點(diǎn)
疑難解答
圖片精選
