having不能直接换成where，因为having作用于分组后结果，where在分组前过滤；强行替换需逻辑重构，如将max(price)>100下推为where price>100，但count(*)>1、avg()等无法无损下推，须用子查询或窗口函数替代。
为什么HAVING不能直接换成WHERE
因为HAVING作用于分组后结果，而WHERE在分组前过滤——这是根本限制。强行“下推”不是语法替换，而是重构逻辑：把原本依赖聚合结果的判断，提前到原始行级别表达。
能下推的典型场景：聚合函数只含常量或单列且无GROUP BY依赖
比如HAVING COUNT(*) > 1无法下推，但HAVING MAX(price) > 100在某些情况下可以——前提是你要确认这个条件等价于“至少有一行满足price > 100”。这时可改写为：
SELECT product_id, MAX(price) FROM sales WHERE price > 100 -- 下推成功：语义一致 GROUP BY product_id HAVING MAX(price) > 100;
注意：WHERE price > 100会先筛掉所有低价行，再聚合，结果和原查询一致；但如果原HAVING是COUNT(*) > 1，就绝不能写成WHERE 1=1之类——没对应行级等价条件。
常见错误：误以为AVG/SUM/COUNT能直接拆解
这些聚合值无法还原为单行判断。例如：
HAVING AVG(score) → 不能写成<code>WHERE score （后者会漏掉高分低分混合但均值不及格的组）-
HAVING COUNT(DISTINCT user_id) > 5→ 无法用WHERE表达，因为去重计数必须分组后才能算 -
HAVING SUM(amount) = 0→ 即使所有amount都是0，也不能靠WHERE amount = 0保证，因为可能有正负相抵的情况
真正可行的下推路径：用子查询或窗口函数替代
当必须把HAVING逻辑前置时，优先考虑：
- 用
EXISTS或IN子查询模拟分组筛选，例如：SELECT * FROM orders WHERE order_id IN (SELECT order_id FROM order_items GROUP BY order_id HAVING SUM(quantity) > 10) - 用窗口函数预计算聚合值，再用
WHERE过滤：SELECT DISTINCT order_id FROM (SELECT order_id, SUM(quantity) OVER(PARTITION BY order_id) AS total_qty FROM order_items) t WHERE total_qty > 10 - 注意性能差异：子查询可能重复扫描，窗口函数在支持的数据库中通常更高效，但MySQL 5.7不支持窗口函数，得退回到子查询
下推是否成立，取决于你能否用原始行数据无损重建那个聚合判断——大多数时候不能，硬推反而引入逻辑错误。
