mysql group by 更快_MYSQL group by 怎么能快一点,之别一根筋

523ac74e6119210ef043d03dd68dab44.png

一般来都有这样一个说法,MYSQL 表的数据超过500万行就不行了,而在这个说法之后就是MYSQL 的group by 的性能奇差无比。

如果要用一句话来说,你把MYSQL 当其他数据库用了(PG, SQL SERVER ,ORACLE),所招致的结果。

3678b6a901a2d8c3aea1cbd179e34bcd.png

select last_name,count(*) from employees where hire_date between '1990-01-01' and '2000-01-01' group by last_name limit 10;

上面是一个查询语句

下面是有索引,没索引,不同索引的查询时间

三种情况,最后将索引落在分组字段的情况下,查询的时间是最短的。

e3d830aea0b0aaef92af728037c8bc74.png

a73f2c32f08ede220c2bb3f2768cc4bb.png

a64cd2db8b793cb736478248cf428eef.png

因为group by实际上执行相同的排序操作,所以group by基本上只是排序后的分组操作,这样,我们就可以一组一组地扫描数据,并动态地执行组。所以在有where 后的条件的索引和GROUP BY 的字段的索引,这样的情况大概率的可能性选择的是分组的索引来进行相关的查询。

当然我们也可以通过,一些参数来强制系统查询的预期结果,例如 SQL_SMALL_RESULT , SQL_BIG_RESULT , SQL_BUFFER_RESULT

c578a546cbfac21567b219a1f9ee3b1d.png我们可以看到三种强制的预期,

1 我们的group by 或 distinct 操作的数据结果集是比较大的,则使用big_result,MYSQL会在磁盘创建临时表,并且很可能走全表扫描的方式

2 如果我们的预设的结果集比较小,则结果集会在内存中进行存储,大家可以看到连香港的 file sort 都不在存在

3 如果希望更快的解锁查询的表,可以选择buffer_result, 将尽快的将表解锁并且将结果存储在本地机,而不是 直接 send data

下面我们来看一个稍微复杂的查询

select d.dept_no,count(s.salary) as count_salary from employees as e

-> left join salaries as s on e.emp_no = s.emp_no

-> left join dept_emp as d on d.emp_no = e.emp_no

-> where e.gender = 'M'

-> group by d.dept_no;

查询的主要目的查询是男性的每个部门的总的工资消耗

57f4b91c734341d4e93be1209c3bf4d4.png

可以看到基本上查询在不到6秒的时间,如何优化这样的查询在MYSQL中。

首先查询的时间过长是一个问题,有的时候我们的想法一般是怎么让这个语句更快的出结果,而加各种的索引,而实际中语句的优化的另一种想法是怎么能让锁表的时间更短,看上去这两者不矛盾,但实际当然其实可能是两种截然不同的思路。

例如上面的语句我这样操作,首先获得所有的部门分组信息的dept_no

fc5914b26d0cba9764366f00e0d31e7d.png

将其保存在程序的缓存中,然后

227a1d29fcc5af285af9416876b17f1d.png

通过下面的语句将每个部门的工资总和获取后,在进行累加的计算(这使用程序来做不是一件困难的事情),最后获得总体的和上面语句一样的结果,而经过实际的操作,整体的查询九个部门的工资最长的不过0.34秒,最短的仅仅0.02秒。整体的查询9次累加的耗时都不超过1 秒。

select d.dept_no,count(s.salary) as count_salary from employees as e  left join salaries as s on e.emp_no = s.emp_no  left join dept_emp as d on d.emp_no = e.emp_no where e.gender = 'M' and d.dept_no = 'd009';

9cdc687c3ba808af2b84c63243363c35.png

通过这样的查询方法,总比死在怎么整体优化一条SQL 要好的多,语句优化,一定要灵活,不要一根筋。当然遇到类似的情况也要分析,如果遇到GROUP BY 就用这样的方法,其实还是一根筋。

8eddeb59fb6c14bdecb5928e1947d957.png

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值