having 混用 where 时性能差因它在 group by 后执行，应将单行过滤条件放 where；having 不支持别名、不可引用未分组字段、不走索引，优化关键在于缩小 group by 输入数据量。
WHERE 和 HAVING 混用时为什么慢得离谱
因为 HAVING 是在分组之后才执行的，如果本该过滤掉大量行的条件写在 HAVING 里，数据库就得先做完整个 GROUP BY（可能生成上万组），再逐组判断——相当于让引擎多干了十倍的活。
- 错误写法：
select user_id, count(*) FROM logs GROUP BY user_id HAVING created_at > '2024-01-01'（created_at是单行字段，不该放HAVING） - 正确做法：把能提前筛数据的条件全塞进
WHERE，比如WHERE created_at > '2024-01-01' GROUP BY user_id - 例外情况：只有涉及聚合结果的判断才必须用
HAVING，比如HAVING COUNT(*) > 5或HAVING AVG(price) > 100
HAVING 子句里用别名会报错吗
会，而且报错方式因数据库而异：postgresql 直接拒绝，mysql（严格模式下）也报错，SQL Server 则允许但语义模糊——别名在 HAVING 中不可靠，不是语法糖，是解析阶段的坑。
- 别名在
HAVING中不可用，哪怕看起来“顺理成章”，例如SELECT user_id AS uid, COUNT(*) AS cnt FROM t GROUP BY user_id HAVING cnt > 10是错的 - 必须写原始表达式：
HAVING COUNT(*) > 10或HAVING COUNT(1) > 10 - 如果聚合表达式复杂（比如
ROUND(AVG(score), 2)），建议重复写，别依赖别名——省事不如省错
GROUP BY 字段没出现在 SELECT 中，HAVING 还能引用吗
不能。标准 SQL 要求：出现在 HAVING 中的非聚合列，必须同时出现在 GROUP BY 子句中；否则就是逻辑矛盾——你都没按它分组，怎么对它做分组后筛选？
- 错误示例：
SELECT user_id, COUNT(*) FROM logs GROUP BY user_id HAVING status = 'active'（status既没聚合也没分组） - 正确解法之一：加进
GROUP BY，变成GROUP BY user_id, status，再HAVING status = 'active' - 更常见解法：把
status过滤前移到WHERE，WHERE status = 'active' GROUP BY user_id -
MySQL默认允许这种写法（sql_mode不含ONLY_FULL_GROUP_BY），但这不是优化，是隐患——换环境就崩
用 HAVING 配合索引还能走索引吗
不能。索引只加速 WHERE、JOIN、ORDER BY 等扫描/定位阶段的操作；HAVING 发生在内存分组之后，属于“结果集后处理”，索引完全不参与。
- 想提速，唯一靠谱路径是：让
WHERE尽可能缩小输入行数，减少GROUP BY的工作量 - 复合索引设计要覆盖
WHERE条件 +GROUP BY字段，例如WHERE category = ? AND created_at > ? GROUP BY user_id，索引应建为(category, created_at, user_id) - 避免在
HAVING里调用函数，比如HAVING date(created_at) = '2024-01-01'——这会让前置的WHERE索引也失效
真正卡住性能的，往往不是 HAVING 本身，而是它前面那步 GROUP BY 处理了多少数据。盯紧 EXPLAIN 输出里的 rows 和 Extra 字段，比背技巧管用得多。