HAVING不能走索引，因其执行于GROUP BY之后的内存分组结果集，而索引仅作用于原始表的物理行；聚合函数结果、分组键输出值均无对应索引结构，优化关键在于将过滤条件尽可能下推至WHERE以减少GROUP BY输入行数。
HAVING 为什么不能走索引
HAVING 子句无法利用索引，根本原因在于它的执行时机——它作用于 GROUP BY 之后的临时分组结果集，而这个结果集已经脱离了原始表的物理存储结构和索引组织。索引是建在原始表（或物化视图）上的 B+ 树结构，只对原始行有效；HAVING 过滤的是每组聚合后的标量值（如 COUNT(*) > 10、AVG(salary) ），这些值不存在于任何索引中。
WHERE 和 HAVING 的执行位置差异
理解这点必须抓住 SQL 执行顺序：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT。
-
WHERE在分组前过滤原始行，可直接命中索引（如WHERE status = 'active'走idx_status） -
HAVING是对GROUP BY输出的内存/临时表进行扫描过滤，哪怕你写HAVING id = 123，这个id也是分组后保留的某个代表值，不是原始索引键 - 即使
HAVING条件里出现的列在GROUP BY中（如GROUP BY user_id HAVING user_id = 100），MySQL 也不会用user_id索引加速该过滤——因为分组已结束，优化器不重走索引路径
哪些“看起来能索引”的 HAVING 实际仍慢
以下写法常被误认为可优化，但实际仍需全分组扫描：
-
HAVING COUNT(*) > 1：聚合函数结果无索引，只能逐组比对 -
HAVING MAX(created_at) > '2026-01-01'：MAX()是计算值，不是索引列本身 -
HAVING user_id IN (100, 200, 300)：虽然user_id有索引，但此处的user_id是分组键输出，非原始行 -
HAVING SUM(amount) BETWEEN 1000 AND 5000：范围判断发生在聚合层，无对应索引结构
真正能缓解 HAVING 性能问题的手段
既然 HAVING 本身不可索引，优化方向只能是减少它要处理的分组数量：
- 把能下推到
WHERE的条件尽量前置，大幅缩小输入行数（例如加WHERE created_at >= '2026-04-01'再分组） - 确认
GROUP BY列是否真的需要高基数；若业务允许，先用WHERE粗筛（如限定region = 'CN'）再分组 - 对高频聚合场景，考虑物化中间结果（如用
CREATE TABLE ... AS SELECT ... GROUP BY+ 单独索引） - MySQL 8.0+ 可评估
CTE+MATERIALIZED提示，但注意物化表本身不自动带索引，需手动添加
别指望给 HAVING 条件建索引——它压根不查表。重点永远是让 GROUP BY 输入更少、更干净。
