MySQL GROUP BY与HAVING的执行顺序与索引利用

掌握 GROUP BY 与 HAVING 的执行顺序及索引利用机制，是编写高效 MySQL 查询的关键。以下指南将直接通过实操步骤，解析查询执行逻辑，并演示如何通过索引优化分组查询性能。

1. 理解 SQL 语句的逻辑执行顺序

在编写或调试 SQL 时，必须明确数据库引擎内部的处理顺序。这决定了索引何时生效，以及数据何时被过滤。

以下是标准的逻辑执行流程：

核心结论：
WHERE 在分组前执行（过滤行），HAVING 在分组后执行（过滤组）。能写在 WHERE 中的条件，绝不要放在 HAVING 中，以便尽早减少数据量。

2. 准备测试环境

为了直观对比索引利用情况，创建 一个测试表并插入模拟数据。

执行 以下 SQL 语句建立表结构：

CREATE TABLE `orders` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `order_amount` decimal(10,2) NOT NULL,
  `order_date` datetime NOT NULL,
  `status` tinyint(1) NOT NULL DEFAULT '1',
  PRIMARY KEY (`id`),
  KEY `idx_user_date` (`user_id`, `order_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

插入 随机测试数据（建议插入 10 万行以上以观察明显差异）：

-- 此处仅为示例，实际测试请使用存储过程批量生成数据
INSERT INTO `orders` (`user_id`, `order_amount`, `order_date`, `status`)
VALUES 
(1, 100.00, '2023-10-01 10:00:00', 1),
(1, 200.00, '2023-10-02 11:00:00', 1),
(2, 150.00, '2023-10-01 12:00:00', 0),
(3, 300.00, '2023-10-03 13:00:00', 1);

3. 分析未优化查询的执行计划

当查询无法利用索引进行分组时，MySQL 通常需要使用“临时表”和“文件排序”，这会极大降低性能。

执行 以下分组查询语句，统计每个用户的订单总额：

SELECT user_id, SUM(order_amount) as total
FROM orders
GROUP BY user_id;

输入 EXPLAIN 命令查看执行计划：

EXPLAIN SELECT user_id, SUM(order_amount) as total FROM orders GROUP BY user_id;

观察 输出结果中的 Extra 字段。如果出现以下内容，说明性能较差：

• Using temporary：MySQL 需要创建临时表来存储分组结果。
• Using filesort：MySQL 需要对结果进行额外的排序操作。

4. 利用索引优化 GROUP BY

MySQL 支持“松散索引扫描”或“紧凑索引扫描”来优化 GROUP BY。要利用这一特性，GROUP BY 后的字段必须与索引列的顺序严格一致。

场景一：利用覆盖索引优化

由于我们已建立联合索引 idx_user_date (user_id, order_date)，我们可以优化只查询索引包含字段的语句。

执行 以下查询：

SELECT user_id, MAX(order_date)
FROM orders
GROUP BY user_id;

查看 执行计划：

EXPLAIN SELECT user_id, MAX(order_date) FROM orders GROUP BY user_id;

观察 Extra 字段。如果显示 Using index for group-by，说明 MySQL 直接利用索引树完成了分组，无需回表查询数据，也无需创建临时表。

场景二：索引顺序的重要性

索引遵循“最左前缀”原则。如果 GROUP BY 的字段顺序与索引不匹配，索引将失效。

执行 以下错误示范查询（按日期分组）：

SELECT order_date, COUNT(*)
FROM orders
GROUP BY order_date;

检查 执行计划，你会发现 type 变为 ALL（全表扫描），且 Extra 包含 Using temporary; Using filesort。

修正 查询，使其匹配索引顺序（user_id 在前）：

SELECT user_id, order_date, COUNT(*)
FROM orders
WHERE order_date > '2023-01-01'
GROUP BY user_id, order_date;

5. 优化 WHERE 与 HAVING 的配合

利用执行顺序原理，将过滤条件尽可能前移到 WHERE 阶段。

低效写法

SELECT user_id, SUM(order_amount) as total
FROM orders
GROUP BY user_id
HAVING user_id > 100;

在此查询中，MySQL 先将所有用户分组聚合，然后再剔除 user_id <= 100 的组。这是对资源的浪费。

高效写法

移动 过滤条件到 WHERE 子句：

SELECT user_id, SUM(order_amount) as total
FROM orders
WHERE user_id > 100
GROUP BY user_id;

对比 两者执行计划。高效写法会在数据读取阶段就利用索引 idx_user_date 中的 user_id 部分进行范围过滤，大大减少进入分组阶段的数据量。

处理聚合函数的情况

如果过滤条件涉及聚合函数（如 SUM(), COUNT()），则必须使用 HAVING，因为此时聚合值尚未计算出来，无法在 WHERE 阶段使用。

执行 以下查询查找订单总额大于 10000 的用户：

SELECT user_id, SUM(order_amount) as total
FROM orders
GROUP BY user_id
HAVING total > 10000;

优化 建议：如果数据量巨大，可以尝试在子查询中先通过 WHERE 过滤掉无关行，再在外层进行 HAVING 过滤。

6. 常见执行计划字段速查表

在优化过程中，使用 EXPLAIN 命令时，请参考以下标准判断查询质量：

7. 实操优化步骤总结

针对现有的慢查询分组语句，请按以下步骤操作：

1. 检查 GROUP BY 后的字段顺序。
2. 确认 是否存在以这些字段为最左前缀的联合索引。
3. 查看 SELECT 列表中的字段。如果只包含索引列和聚合函数，更有可能触发“覆盖索引”。
4. 审查 HAVING 子句中的条件。如果是非聚合列条件，将其移至 WHERE 子句。
5. 运行 EXPLAIN 命令。
6. 确认 Extra 列中消除了 Using temporary 和 Using filesort，或者出现了 Using index for group-by。