聚合函数本身不导致非SARGable，问题在于WHERE中使用聚合（如COUNT、MAX）或在索引列上应用聚合函数；HAVING因作用于分组后结果而无法利用索引，必须先完成GROUP BY再过滤。
聚合函数本身不会直接导致非SARGable查询，问题出在**把聚合函数用在WHERE子句或索引列上做条件判断**——这时数据库无法利用索引快速定位数据行。
WHERE里写MAX()、COUNT()就彻底非SARGable
比如这条语句：
SELECT * FROM orders WHERE COUNT(*) > 100;
根本执行不了，语法错误。但更隐蔽的陷阱是这种写法：
SELECT customer_id FROM orders GROUP BY customer_id HAVING MAX(order_time) > '2023-01-01';
HAVING不是WHERE，它作用于分组后的结果集，不走索引扫描；而MAX(order_time)是在每组内计算，数据库必须先完成全部分组（可能触发临时表+文件排序），再过滤。整个过程完全绕过索引。
- WHERE子句只允许对**原始行**做条件筛选，才能利用索引
- HAVING是对**聚合后结果**筛选，MySQL必须先执行GROUP BY，再逐个检查HAVING条件
- 哪怕order_time上有索引，MAX(order_time)也无法下推到扫描阶段使用
SELECT列表里的聚合函数不影响SARGability，但会误导人
这条SQL是SARGable的：
SELECT customer_id, COUNT(*) FROM orders WHERE order_time >= '2023-01-01' GROUP BY customer_id;
因为WHERE条件order_time >= '2023-01-01'本身可走索引，聚合发生在筛选之后。但很多人误以为“用了COUNT就慢”，其实瓶颈不在COUNT，而在：
- GROUP BY字段没索引 → 触发filesort
- SELECT * + GROUP BY → 引发回表或临时表
- 数据倾斜导致某customer_id分组极大，单组计算耗时飙升
想让聚合类查询变快，关键不是避免聚合函数，而是分离“筛选”和“聚合”
真正有效的做法是把高选择性的过滤条件留在WHERE里，用索引快速剪枝，再聚合剩余数据：
- 把时间范围、状态码、ID区间等能走索引的条件全塞进WHERE
- 避免在WHERE里对列用函数：
YEAR(order_time) = 2023→ 改成order_time >= '2023-01-01' AND order_time - 如果必须按聚合结果筛选（如“订单数>5的客户”），优先考虑用子查询或CTE预计算，而非HAVING
- 对高频聚合场景，提前物化结果到汇总表，避免每次实时算
最易被忽略的一点：EXPLAIN看type字段。只要出现ALL或index，说明WHERE没走有效索引——此时再优化COUNT或SUM毫无意义，得先解决筛选路径问题。
