where和group by顺序不可颠倒，因sql执行顺序为where→group by→having，where在分组前执行，无法访问聚合值，必须用having过滤分组结果。
WHERE 和 GROUP BY 的顺序不能颠倒
SQL 执行顺序决定了你不能在 GROUP BY 之后用 WHERE 过滤聚合结果——那是 HAVING 的职责。很多人写成：SELECT COUNT(*) FROM t GROUP BY x WHERE COUNT(*) > 1，直接报错 ERROR 1064，因为 WHERE 看不到聚合值。
真正可行的路径是：先用 WHERE 做行级过滤（比如状态=‘active’、时间在某范围内），再 GROUP BY，最后用 HAVING 对分组结果做条件筛选。
- 前置条件（如多字段联合判断、子查询结果）必须放在
WHERE或JOIN ON中，而不是塞进HAVING - 如果前置条件依赖聚合值（例如“每个用户最近3次操作中至少有2次成功”），就得用窗口函数或子查询提前算好标记位，再进主查询
-
HAVING只能引用GROUP BY列或聚合函数，不能引用原始表中未分组的普通列
用窗口函数预计算再去重，比嵌套子查询更稳
当“复杂前置条件”涉及排序、排名、累计值（比如“取每个 category 下 price 最高的前3条”），硬靠 GROUP BY 会丢数据——它只留分组代表行，不保留原始记录上下文。
更可靠的做法是：用 ROW_NUMBER() 或 RANK() 在子查询/CTE 中打标，再在外层 WHERE 过滤标记，最后 COUNT(DISTINCT ...)。
WITH ranked AS (
SELECT user_id, category,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC) as rn
FROM events
WHERE created_at >= '2024-01-01' AND status = 'done'
)
SELECT COUNT(DISTINCT user_id)
FROM ranked
WHERE rn
- 注意
PARTITION BY必须和你要“去重”的维度一致（比如按user_id去重，就别在PARTITION BY里漏掉它） -
ROW_NUMBER()和RANK()在并列值处理上不同，影响最终计数结果，需按业务选 - MySQL 8.0+、PostgreSQL、SQL Server 支持；旧版 MySQL 需用变量模拟，容易出错
COUNT(DISTINCT ...) 在 JOIN 后可能被放大
如果前置条件要关联多表（比如“统计同时满足订单状态=‘paid’且用户等级>=VIP2’的客户数”），直接 JOIN 再 COUNT(DISTINCT user_id) 看似合理，但一对多关系会让同一 user_id 出现多次，DISTINCT 虽能去重，性能却可能崩——尤其大表 JOIN 后临时结果集爆炸。
- 优先把 JOIN 条件尽可能收窄：比如在
ON子句里加AND o.status = 'paid'，而非全量 JOIN 后再WHERE - 更彻底的解法是改用
EXISTS或IN替代JOIN，避免笛卡尔积风险 - 某些引擎（如 Hive）对
COUNT(DISTINCT)有内存限制，大数据量时建议改用近似函数APPROX_COUNT_DISTINCT
NULL 值会让 COUNT(DISTINCT) 和 GROUP BY 行为不一致
COUNT(DISTINCT col) 会忽略 NULL，但 GROUP BY col 会把所有 NULL 归为一组——这意味着，如果你前置条件里允许 col IS NULL，而后续又依赖 GROUP BY 分组数来反推去重数，结果一定不对。
典型陷阱：想统计“有邮箱或手机号的用户数”，写成 COUNT(DISTINCT COALESCE(email, phone))。一旦 email 和 phone 都为 NULL，COALESCE 返回 NULL，这条记录就被 COUNT(DISTINCT) 直接跳过，但业务上你可能希望它算作一个“无联系方式用户”。
- 明确区分“去重计数”目标：是去重非空值？还是去重所有有效标识（含 NULL 单独一类）？
- 需要把
NULL当作合法值参与去重时，用COUNT(DISTINCT CASE WHEN ... THEN x ELSE 'NULL_PLACEHOLDER' END) - MySQL 中
GROUP BY对NULL的处理与 PostgreSQL 一致，但某些 OLAP 引擎（如 ClickHouse）默认把NULL视为相同值，细节得查文档
