MySQL优化GROUP BY－松散索引扫描与紧凑索引扫描

MySQL优化GROUP BY－松散索引扫描与紧凑索引扫描

       由于GROUP BY 实际上也同样会进行排序操作，而且与ORDER BY 相比，GROUP BY 主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函数的计算。所以，在GROUP BY 的实现过程中，与 ORDER BY 一样也可以利用到索引。在MySQL 中，GROUP BY 的实现同样有多种（三种）方式，其中有两种方式会利用现有的索引信息来完成 GROUP BY，另外一种为完全无法使用索引的场景下使用。下面我们分别针对这三种实现方式做一个分析。

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

对“松散索引扫描”的定义，本人看了很多网上的介绍，都不甚明白。在此逻列如下：

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

定义2：优化Group By最有效的办法是当可以直接使用索引来完全获取需要group的字段。使用这个访问方法时，MySQL使用对关键字排序的索引的类型（比如BTREE索引）。这使得索引中用于group的字段不必完全涵盖WHERE条件中索引对应的key。由于只包含索引中关键字的一部分，因此称为松散的索引扫描。
意思是索引中用于group的字段，没必要包含多列索引的全部字段。例如：有一个索引idx(c1,c2,c3)，那么group by c1、group by c1,c2这样c1或c1、c2都只是索引idx的一部分。要注意的是，索引中用于group的字段必须符合索引的“最左前缀”原则。group by c1,c3是不会使用松散的索引扫描的

例如：

explain

SELECT group_id,gmt_create
FROM group_message
WHERE user_id>1
GROUP BY group_id,gmt_create;

本人理解“定义2”的例子说明

有一个索引idx(c1,c2,c3)

SELECT c1, c2 FROM t1 WHERE c1 < const GROUP BY c1, c2;

索引中用于group的字段为c1,c2
不必完全涵盖WHERE条件中索引对应的key（where条件中索引，即为c1；c1对应的key，即为idx）
索引中用于group的字段(c1,c2)只包含索引中关键字(c1,c2,c3)的一部分，因此称为松散的索引扫描。

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

◆ 查询针对一个单表

◆ GROUP BY 条件字段必须在同一个索引中最前面的连续位置；
GROUP BY包括索引的第1个连续部分(如果对于GROUP BY，查询有一个DISTINCT子句，则所有DISTINCT的属性指向索引开头)。

◆ 在使用GROUP BY 的同时，如果有聚合函数，只能使用 MAX 和 MIN 这两个聚合函数，并且它们均指向相同的列。

◆ 如果引用(where条件中)到了该索引中GROUP BY 条件之外的字段条件的时候，必须以常量形式存在，但MIN()或MAX() 函数的参数例外；
或者说：索引的任何其它部分（除了那些来自查询中引用的GROUP BY）必须为常数(也就是说，必须按常量数量来引用它们)，但MIN()或MAX() 函数的参数例外。

补充：如果sql中有where语句，且select中引用了该索引中GROUP BY 条件之外的字段条件的时候，where中这些字段要以常量形式存在。

◆ 如果查询中有where条件，则条件必须为索引，不能包含非索引的字段

松散索引扫描
explain

SELECT group_id,user_id
FROM group_message
WHERE group_id between 1 and 4
GROUP BY group_id,user_id;

松散索引扫描
explain

SELECT group_id,user_id
FROM group_message
WHERE user_id>1 and group_id=1
GROUP BY group_id,user_id;

非松散索引扫描
explain

SELECT group_id,user_id
FROM group_message
WHERE abc=1
GROUP BY group_id,user_id;

非松散索引扫描
explain

SELECT group_id,user_id
FROM group_message
WHERE user_id>1 and abc=1
GROUP BY group_id,user_id;

松散索引扫描，此类查询的EXPLAIN输出显示Extra列的Using index for group-by

下面的查询提供该类的几个例子，假定表t1(c1,c2,c3,c4)有一个索引idx(c1，c2，c3)：

SELECT c1, c2 FROM t1 GROUP BY c1, c2;

SELECT DISTINCT c1, c2 FROM t1;

SELECT c1, MIN(c2) FROM t1 GROUP BY c1;

SELECT c1, c2 FROM t1 WHERE c1 < const GROUP BY c1, c2;

SELECT MAX(c3), MIN(c3), c1, c2 FROM t1 WHERE c2 > const GROUP BY c1, c2;

SELECT c2 FROM t1 WHERE c1 < const GROUP BY c1, c2;

SELECT c1, c2 FROM t1 WHERE c3 = const GROUP BY c1, c2；

由于上述原因，不能用该快速选择方法执行下面的查询：

1、除了MIN()或MAX()，还有其它累积函数，例如：

SELECT c1, SUM(c2) FROM t1 GROUP BY c1;

2、GROUP BY子句中的域不引用索引开头，如下所示：

SELECT c1,c2 FROM t1 GROUP BY c2, c3;

3、查询引用了GROUP BY部分后面的关键字的一部分，并且没有等于常量的等式，例如：

SELECT c1,c3 FROM t1 GROUP BY c1, c2；

这个例子中，引用到了c3（c3必须为组合索引中的一个），因为group by 中没有c3。并且没有等于常量的等式。所以不能使用松散索引扫描

可以这样改一下：

SELECT c1,c3 FROM t1 where c3='a' GROUP BY c1, c2

下面这个例子不能使用松散索引扫描

SELECT c1,c3 FROM t1 where c3='a' GROUP BY c1, c2

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

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

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

紧凑索引扫描实现 GROUP BY 和松散索引扫描的区别主要在于：

紧凑索引扫描需要在扫描索引的时候，读取所有满足条件的索引键，然后再根据读取出的数据来完成 GROUP BY 操作得到相应结果。

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

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

当 GROUP BY 条件字段并不连续或者不是索引前缀部分的时候，MySQL Query Optimizer 无法使用松散索引扫描。

这时检查where 中的条件字段是否有索引的前缀部分，如果有此前缀部分，且该部分是一个常量，且与group by 后的字段组合起来成为一个连续的索引。这时按紧凑索引扫描。

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

需读取group_id=2的所有数据，然后在读取的数据中完成group by操作得到结果。（这里group by 字段并不是一个连续索引，正好where 中group_id正好弥补缺失的索引键，又恰好是一个常量，因此使用紧凑索引扫描）

group_id user_id 这个顺序是可以使用该索引。如果连接的顺序不符合索引的“最左前缀”原则，则不使用紧凑索引扫描。

以下例子使用紧凑索引扫描

GROUP BY中有一个差距，但已经由条件user_id = 1覆盖。

explain

SELECT group_id,gmt_create
FROM group_message
WHERE user_id = 1 GROUP BY group_id,gmt_create

GROUP BY不以关键字的第1个元素开始，但是有一个条件提供该元素的常量
explain

SELECT group_id,gmt_create
FROM group_message
WHERE group_id = 1 GROUP BY user_id,gmt_create

下面的例子都不使用紧凑索引扫描

user_id,gmt_create 连接起来并不符合索引“最左前缀”原则
explain

SELECT group_id,gmt_create
FROM group_message
WHERE user_id = 1 GROUP BY gmt_create

group_id,gmt_create 连接起来并不符合索引“最左前缀”原则

explain

SELECT gmt_create
FROM group_message
WHERE group_id=1 GROUP BY gmt_create;

 3、使用临时表实现 GROUP BY

MySQL Query Optimizer 发现仅仅通过索引扫描并不能直接得到 GROUP BY 的结果之后，他就不得不选择通过使用临时表然后再排序的方式来实现 GROUP BY了。在这样示例中即是这样的情况。 group_id 并不是一个常量条件，而是一个范围，而且 GROUP BY 字段为 user_id。所以 MySQL 无法根据索引的顺序来帮助 GROUP BY 的实现，只能先通过索引范围扫描得到需要的数据，然后将数据存入临时表，然后再进行排序和分组操作来完成 GROUP BY。

explain

SELECT group_id
FROM group_message
WHERE group_id between 1 and 4
GROUP BY user_id;

示例数据库文件

-- --------------------------------------------------------
-- Host: 127.0.0.1
-- Server version: 5.1.57-community - MySQL Community Server (GPL)
-- Server OS: Win32
-- HeidiSQL version: 7.0.0.4156
-- Date/time: 2012-08-20 16:52:10
-- --------------------------------------------------------

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET FOREIGN_KEY_CHECKS=0 */;

-- Dumping structure for table test.group_message
DROP TABLE IF EXISTS `group_message`;
CREATE TABLE IF NOT EXISTS `group_message` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`group_id` int(10) unsigned DEFAULT NULL,
`user_id` int(10) unsigned DEFAULT NULL,
`gmt_create` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`abc` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `group_id_user_id_gmt_create` (`group_id`,`user_id`,`gmt_create`)
) ENGINE=MyISAM AUTO_INCREMENT=27 DEFAULT CHARSET=utf8;

-- Dumping data for table test.group_message: 0 rows
DELETE FROM `group_message`;
/*!40000 ALTER TABLE `group_message` DISABLE KEYS */;
INSERT INTO `group_message` (`id`, `group_id`, `user_id`, `gmt_create`, `abc`) VALUES
(1, 1, 1, '2012-08-20 09:25:35', 1),
(2, 2, 1, '2012-08-20 09:25:39', 1),
(3, 2, 2, '2012-08-20 09:25:47', 1),
(4, 3, 1, '2012-08-20 09:25:50', 2),
(5, 3, 2, '2012-08-20 09:25:52', 2),
(6, 3, 3, '2012-08-20 09:25:54', 0),
(7, 4, 1, '2012-08-20 09:25:57', 0),
(8, 4, 2, '2012-08-20 09:26:00', 0),
(9, 4, 3, '2012-08-20 09:26:02', 0),
(10, 4, 4, '2012-08-20 09:26:06', 0),
(11, 5, 1, '2012-08-20 09:26:09', 0),
(12, 5, 2, '2012-08-20 09:26:12', 0),
(13, 5, 3, '2012-08-20 09:26:13', 0),
(14, 5, 4, '2012-08-20 09:26:15', 0),
(15, 5, 5, '2012-08-20 09:26:17', 0),
(16, 6, 1, '2012-08-20 09:26:20', 0),
(17, 7, 1, '2012-08-20 09:26:23', 0),
(18, 7, 2, '2012-08-20 09:26:28', 0),
(19, 8, 1, '2012-08-20 09:26:32', 0),
(20, 8, 2, '2012-08-20 09:26:35', 0),
(21, 9, 1, '2012-08-20 09:26:37', 0),
(22, 9, 2, '2012-08-20 09:26:40', 0),
(23, 10, 1, '2012-08-20 09:26:42', 0),
(24, 10, 2, '2012-08-20 09:26:44', 0),
(25, 10, 3, '2012-08-20 09:26:51', 0),
(26, 11, 1, '2012-08-20 09:26:54', 0);
/*!40000 ALTER TABLE `group_message` ENABLE KEYS */;
/*!40014 SET FOREIGN_KEY_CHECKS=1 */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

参考文献

1、MySQL如何优化GROUP BY http://www.iteedu.com//database/mysql/mysqlmanualcn/optimization/group-by-optimization.php
2、详解MySQL分组查询Group By实现原理 http://www.51testing.com/html/52/n-229952.html
3、松散的索引扫描(Loose index scan) http://www.coder4.com/archives/1344
4、MySQL学习笔记 http://leeon.me/a/mysql-notes-2