HAVING不能直接用B树索引过滤，因其作用于分组后动态计算的聚合结果（如COUNT(*)>5），而B树索引仅存储原始行数据，无法预存或定位聚合值；仅当HAVING条件可下推为行级过滤（如dept='tech'）时，才可能利用索引。
GROUP BY + HAVING 为什么不能直接用 B 树索引过滤？
因为 HAVING 是在分组后对聚合结果做筛选，而 B 树索引只能加速「行级」条件的查找（比如 WHERE user_id = 123），无法跳过分组过程直接定位到某个 COUNT(*) > 5 的分组——这个值根本不存在于索引叶节点中，是执行时动态算出来的。
HAVING 条件能走索引的唯一机会：被下推到 WHERE
如果 HAVING 中的条件其实等价于对原始行的限制（即不依赖聚合函数），优化器可能把它“下推”成 WHERE 条件，这时就能用索引。例如：
SELECT dept, COUNT(*) FROM emp GROUP BY dept HAVING dept = 'tech';
这等价于先 WHERE dept = 'tech' 再分组，dept 列上有 B 树索引就能用上。但下面这个就完全不行：
SELECT dept, COUNT(*) FROM emp GROUP BY dept HAVING COUNT(*) > 5;
因为 COUNT(*) > 5 必须等所有分组算完才可判断，索引没法预判哪组会满足。
-
HAVING含聚合函数（COUNT、SUM、AVG等）→ 100% 不走索引过滤 -
HAVING只含分组列的等值/范围条件 → 有可能被下推，取决于优化器是否识别 - MySQL 8.0+ 和 PostgreSQL 在某些场景下会尝试物化中间分组结果并加临时索引，但这是执行期行为，不是走原表 B 树索引
想加速 HAVING 过滤，实际能做的几件事
别指望靠加索引让 HAVING COUNT(*) > 100 变快；得从执行路径本身入手：
- 先用
WHERE尽量缩小输入行数（比如加时间范围、状态过滤），减少分组基数 - 确保
GROUP BY列有 B 树索引——它不加速HAVING，但能加速分组本身的排序/哈希构建（尤其 MySQL 的GROUP BY默认隐式排序） - 对高频聚合查询，考虑用物化视图（PostgreSQL）或汇总表（MySQL）预先算好
COUNT结果并建索引 - 用
LIMIT配合HAVING无意义——HAVING是分组后筛选，LIMIT是最终结果截断，两者不联动
一个容易被忽略的性能陷阱：ORDER BY + HAVING 混用
写成 GROUP BY x HAVING COUNT(*) > 1 ORDER BY COUNT(*) DESC，很多人以为索引能帮上忙。实际上：
- B 树索引无法按
COUNT(*)排序，因为该值不在索引里 - 数据库必须先完成全部分组、计算每个组的
COUNT、过滤、再排序——三步全内存/磁盘操作 - 如果分组数极大（比如百万个
user_id），这个查询极易 OOM 或触发临时表磁盘写
真正要优化这种场景，得放弃实时聚合，改用预计算 + 覆盖索引查汇总表。
