loose index scan 优化distinct

简介:

上篇中我们提到用伪loose index scan来优化max/min,这一篇我们将用伪loose index scan来优化distinct:

有这样的一个需求:select count(distinct nick) from user_access_xx_xx;

这条sql用于统计用户访问的uv,由于单表的数据量在10G以上,即使在user_access_xx_xx上加上nick的索引,

通过查看执行计划,也为全索引扫描,sql在执行的时候,会对整个服务器带来抖动;

root@db 09:00:12>select count(distinct nick) from user_access;

+———————-+

| count(distinct nick) |

+———————-+

|               806934 |

+———————-+

1 row in set (52.78 sec)

执行一次sql需要花费52.78s,已经非常的慢了

现在需要换一种思路来解决该问题:

我们知道索引的值是按照索引字段升序的,比如我们对(nick,other_column)两个字段做了索引,那么在索引中的则是按照nick,other_column的升序排列:

我们现在的sql:select count(distinct nick) from user_access;则是直接从nick1开始一条条扫描下来,直到扫描到最后一个nick_n,

那么中间过程会扫描很多重复的nick,如果我们能够跳过中间重复的nick,则性能会优化非常多(在oracle中,这种扫描技术为loose index scan,但在5.1的版本中,mysql中还不能直接支持这种优化技术):

 

 

 

 

 

 

所以需要通过改写sql来达到伪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) 实现了上图中的伪loose index scan,优化器在这个时候的执行计划为Using index for group-by ,

需要注意的是mysql把distinct优化为group by,它首先利用索引来分组,然后扫描索引,对需要的nick只扫描一次;

两个sql的执行计划分别为:

优化写法:

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 |

目录
相关文章
|
SQL 索引
count(1) and count(column)那个更优?
count(1) and count(column)那个更优?
66 0
|
存储 SQL 架构师
性能大PK count(*)、count(1)和count(列)
最近的工作中,我听到组内两名研发同学在交流数据统计性能的时候,聊到了以下内容: 数据统计你怎么能用 count(*) 统计数据呢,count(*) 太慢了,要是把数据库搞垮了那不就完了么,赶紧改用 count(1),这样比较快...... 有点儿好奇,难道 count(1) 的性能真的就比 count(*) 要好吗? 印象中网上有很多的文章都有过类似问题的讨论,那 MySQL 统计数据总数 count(*) 、count(1)和count(列名) 哪个性能更优呢?今天我们就来聊一聊这个问题。
性能大PK count(*)、count(1)和count(列)
|
SQL 存储 Oracle
PostgreSQL 分页, offset, 返回顺序, 扫描方法原理(seqscan, index scan, index only scan, bitmap scan, parallel xx scan),游标
PostgreSQL 分页, offset, 返回顺序, 扫描方法原理(seqscan, index scan, index only scan, bitmap scan, parallel xx scan),游标
3719 0
|
SQL 关系型数据库 MySQL
随笔:MySQL:eq_range_index_dive_limit 索引下探接口
我的测试记录 一、概述 这个参数会影响到执行计划在评估的时候到底使用统计数据还是进行实际的所以你访问,那么很显然如下: 使用统计数据生成执行计划的效率更高。 使用索引实际访问,及索引下探会代价更高但是更加准确。
4952 0
|
关系型数据库 PostgreSQL
PostgreSQL sharding : citus 系列7 - topn 加速(count(*) group by order by count(*) desc limit x) (use 估值插件 topn)
标签 PostgreSQL , topn , topn.number_of_counters , count(*) group by order by count(*) desc limit x 背景 count(*) group by order by count(*) desc limit x 用来统计 topn。
1370 0