您的位置:首页 > 其它

使用子查询来提升distinct count

2017-10-10 11:56 162 查看
转自:
http://blog.csdn.net/z69183787/article/details/51732887
Count distinct是SQL分析时的祸根,因此它是我第一篇博客的不二选择。
首先:如果你有一个大的且能够容忍不精确的数据集,那像HyperLogLog这样的概率计数器应该是你最好的选择。(我们会在以后的博客中谈到HyperLogLog。)但对于需要快速、精准答案的查询,一些简单的子查询可以节省你很多时间。






Garfielt

翻译于 2年前

3人顶

顶 翻译的不错哦!
让我们以我们一直使用的一个简单查询开始:哪个图表的用户访问量最大?

?
首先,我们假设user_id和dashboard_id上已经设置了索引,且有比图表和用户数多得多的日志条目。
一千万行数据时,查询需要48秒。要知道原因让我们看一下SQL解析:



它慢是因为数据库遍历了所有日志以及所有的图表,然后join它们,再将它们排序,这些都在真正的group和分组和聚合工作之前。





Garfielt

翻译于 2年前

3人顶

顶 翻译的不错哦!


先聚合,然后Join

group-聚合后的任何工作代价都要低,因为数据量会更小。group-聚合时我们不需使用dashboards.name,我们也可以先在数据库上做聚集,在join之前:

?
现在查询运行了20秒,提升了2.4倍。再次通过解析来看一下原因:



正如设计的,group-聚合在join之前。而且,额外的我们可以利用time_on_site_logs表里的索引。






Garfielt

翻译于 2年前

2人顶

顶 翻译的不错哦!


首先,缩小数据集

我们可以做的更好。通过在整个日志表上group-聚合,我们处理了数据库中很多不必要的数据。Count distinct为每个group生成一个哈希——在本次环境中为每个dashboard_id——来跟踪哪些bucket中的哪些值已经检查过。
我们可以预先计算差异,而不是处理全部数据,这样只需要一个哈希集合。然后我们在此基础上做一个简单的聚集即可。

?
我们采取内部的count-distinct-group,然后将数据拆成两部分分成两块。第一块计算distinct (dashboard_id, user_id) 。第二块在它们基础上运行一个简单group-count。跟上面一样,最后再join。









Garfielt

翻译于 2年前

2人顶

顶 翻译的不错哦!
呵呵,大发现:这样只需要0.7秒!这比上面的查询快28倍,比原来的快了68倍。
通常,数据大小和类型很重要。上面的例子受益于基数中没多少换算。distinct (user_id, dashboard_id)相对于数据总量来说数量也很少。不同的对数越多,用来group和计数的唯一数据就越多——代价便会越来越大。
下一遇到长时间运行的count distinct时,尝试一些子查询来减负吧。

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: