mysql中group by的实现与优化

参考：https://phpmianshi.com/?id=154

概念

    由于 GROUP BY 实际上也同样需要进行排序操作，而且与 ORDER BY 相比，GROUP BY 主要只是多了 排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函 数的计算。所以，在 GROUP BY 的实现过程中，与 ORDER BY 一样也可以利用到索引。

 

  在 MySQL 中，GROUP BY 的实现同样有多种（三种）方式，其中有两种方式会利用现有的索引信息 来完成 GROUP BY，另外一种为完全无法使用索引的场景下使用。下面我们分别针对这三种实现方式做一个分析。

 

1. 使用松散（Loose）索引扫描实现 GROUP BY

 

  何谓松散索引扫描实现 GROUP BY 呢？实际上就是当 MySQL 完全利用索引扫描来实现 GROUP BY 的 时候，并不需要扫描所有满足条件的索引键即可完成操作得出结果。

 

  下面我们通过一个示例来描述松散索引扫描实现 GROUP BY，在示例之前我们需要首先调整一下 group_message 表的索引，将 gmt_create 字段添加到 group_id 和 user_id 字段的索引中： 

 

create index idx_gid_uid_gc
on group_message(group_id,user_id,gmt_create);

EXPLAIN SELECT user_id,max(gmt_create) 
FROM group_message 
WHERE group_id < 10 
GROUP BY group_id,user_id\G

只列重点：

*************************** 1. row ***************************

key: idx_gid_uid_gc 

Extra: Using where; Using index for group-by 

Extra 信息中有信息显示“Using index for group-by”，实际上这就是告 诉我们，MySQL Query Optimizer 通过使用松散索引扫描来实现了我们所需要的 GROUP BY 操作。执行流程如下：

 

 

要利用到松散索引扫描实现 GROUP BY，需要至少满足以下几个条件： 

◆ GROUP BY 条件字段必须在同一个索引中最前面的连续位置； 

◆ 在使用 GROUP BY 的同时，只能使用 MAX 和 MIN 这两个聚合函数； 

◆ 如果引用到了该索引中 GROUP BY 条件之外的字段条件的时候，必须以常量形式存在；

 

为什么松散索引扫描的效率会很高？ 

因为在没有 WHERE 子句，也就是必须经过全索引扫描的时候， 松散索引扫描需要读取的键值数量与 分组的组数量一样多，也就是说比实际存在的键值数目要少很多。而在 WHERE 子句包含范围判断式或者 等值表达式的时候， 松散索引扫描查找满足范围条件的每个组的第 1 个关键字，并且再次读取尽可能最少数量的关键字。

 

2. 使用紧凑（Tight）索引扫描实现 GROUP BY

    紧凑索引扫描实现 GROUP BY 和松散索引扫描的区别主要在于他需要在扫描索引的时候，读取所有满足条件的索引键，然后再根据读取的数据来完成 GROUP BY 操作得到相应结果。

EXPLAIN SELECT max(gmt_create) 
FROM group_message 
WHERE group_id = 2 
GROUP BY user_id\G

只列重点：

*************************** 1. row ***************************

key: idx_gid_uid_gc

Extra: Using where; Using index

 

这时候的执行计划的 Extra 信息中已经没有“Using index for group-by”了，但并不是说 MySQL 的 GROUP BY 操作并不是通过索引完成的，只不过是需要访问 WHERE 条件所限定的所有索引键信息之后才能得出结果。这就是通过紧凑索引扫描来实现 GROUP BY 的执行计划输出信息。

 

 MySQL Query Optimizer 首先会选择尝试通过松散索引扫描来实现 GROUP BY 操作， 当发现某些情况无法满足松散索引扫描实现 GROUP BY 的要求之后，才会尝试通过紧凑索引扫描来实现。

当 GROUP BY 条件字段并不连续或者不是索引前缀部分的时候，MySQL Query Optimizer 无法使用松散索引扫描，因为缺失的索引键信息无法得到。但是， 如果 Query 语句中存在一个常量值来引用缺失的索引键，因为常量填充了搜索关键字中的“差距”，可以形成完整的索引前缀。这些索引前缀可以用于索引查找。那么此时mysql的执行过程为先根据where语句进行一次选择，对选出来的结果集，可以利用索引。这种方式，从整体上来说，group by并没有利用索引，但是从过程来说，在选出的结果中利用了索引，这种方式就是紧凑索引。

 

 

3. 使用临时表实现 GROUP BY

     MySQL 在进行 GROUP BY操作的时候想要利用索引，必须满足 GROUP BY 的字段必须同时存放于同一个索引中，且该索引是一个有序索引（如 Hash 索引就不能满足要求）。而且，并不只是如此，是否能够利用索引来实现 GROUP BY 还与使用的聚合函数也有关系。 前面两种 GROUP BY 的实现方式都是在有可以利用的索引的时候使用的，当 MySQL Query Optimizer 无法找到合适的索引可以利用的时候，就不得不先读取需要的数据，然后通过临时表来完成 GROUP BY 操作。

 

EXPLAIN SELECT max(gmt_create) FROM group_message WHERE group_id > 1 and group_id < 10 GROUP BY user_id\G

只列重点：

*************************** 1. row ***************************

key: idx_gid_uid_gc

Extra: Using where; Using index; Using temporary; Using filesort

 

这次的执行计划非常明显的告诉我们 MySQL 通过索引找到了我们需要的数据，然后创建了临时表， 又进行了排序操作，才得到我们需要的 GROUP BY 结果。整个执行过程大概如下图所展示：

 

当 MySQL Query Optimizer 发现仅仅通过索引扫描并不能直接得到 GROUP BY 的结果之后，他就不得不选择通过使用临时表然后再排序的方式来实现 GROUP BY 了。 

 

group_id 并不是一个常量条件，而是一个范围，而且 GROUP BY 字段为 user_id。所以 MySQL无法根据索引的顺序来帮助 GROUP BY 的实现，只能先通过索引范围扫描 得到需要的数据，然后将数据存入临时表，然后再进行排序和分组操作来完成 GROUP BY。

 

对于上面三种 MySQL 处理 GROUP BY 的方式，我们可以针对性的得出如下两种优化思路： 

1. 尽可能让 MySQL 可以利用索引来完成 GROUP BY 操作，当然最好是松散索引扫描的方式最佳。 在系统允许的情况下，我们可以通过调整索引或者调整 Query 这两种方式来达到目的； 

2. 当无法使用索引完成 GROUP BY 的时候，由于要使用到临时表且需要 filesort，所以我们必须要有足够的 sort_buffer_size 来供 MySQL 排序的时候使用，而且尽量不要进行大结果集的 GROUP BY 操作，因为如果超出系统设置的临时表大小的时候会出现将临时表数据 copy 到磁盘上面再进行操作，这时候的排序分组操作性能将是成数量级的下降； 

 

至于如何利用好这两种思路，还需要大家在自己的实际应用场景中不断的尝试并测试效果，最终才能得到较佳的方案。此外，在优化 GROUP BY 的时候还有一个小技巧可以让我们在有些无法利用到索引的情况下避免 filesort 操作，也就是在整个语句最后添加一个以 null 排序（ORDER BY null）的子句，大家可以尝试一下试试看会有什么效果。