count失真源于上下文错误：join未去重导致行膨胀、group by粒度不当、having与where混淆、null值未处理、distinct字段含高唯一性列或前缀索引限制。
GROUP BY没写或写错，COUNT就变成“数连接后的行”
不是COUNT本身出错，而是它在错误的上下文中被调用。最常见的现象是：JOIN之后直接GROUP BY user_id，但没意识到一条用户记录关联了5条订单，结果COUNT(*)返回5——你以为在数“用户数”，实际在数“连接后产生的行数”。
- 先确认是否用了JOIN：如果视图或子查询里有
JOIN，且没提前去重，COUNT几乎必然被放大 - 检查
GROUP BY字段是否真正代表业务维度：比如GROUP BY user_id, order_id会让每组最多1行，COUNT(*)永远是1 - 用
SELECT COUNT(*) FROM joined_result和SELECT COUNT(*) FROM users对比，差值大说明膨胀已发生
HAVING写成WHERE，或者根本没写GROUP BY
COUNT(*)是聚合函数，只能在分组后计算。写WHERE COUNT(*) > 1会直接报错；漏掉GROUP BY又写HAVING，数据库要么报错，要么返回空——因为没分组对象可筛。
-
WHERE只能过滤原始行（如WHERE status = 'active'） -
HAVING必须紧跟GROUP BY，用于筛选分组结果（如HAVING COUNT(*) > 1） - 想查“哪些user_id重复出现”，必须写
GROUP BY user_id，否则HAVING无意义
COUNT(DISTINCT)被误用，或分组粒度太细
COUNT(DISTINCT column)本意是去重计数，但如果GROUP BY里混入了order_id、created_at这类高唯一性字段，每组只剩1行，COUNT(DISTINCT)自然也变成1。
- 检查
GROUP BY子句：只保留业务维度字段，如user_id、date_trunc('day', created_at)，别带明细ID或毫秒级时间 - 验证去重逻辑：运行
SELECT COUNT(*), COUNT(DISTINCT product_id) FROM orders GROUP BY user_id，若两列数值接近，说明分组过细 - MySQL 8.0+要注意前缀索引：如果
product_id是VARCHAR(255)但只建了INDEX(product_id(10))，COUNT(DISTINCT)只基于前10字符去重
NULL值干扰分组，导致重复被“隐形忽略”
多数数据库中，NULL = NULL为FALSE，所以多个NULL不会被归入同一组——你查GROUP BY phone HAVING COUNT(*) > 1，但一堆空手机号根本不出现在结果里。
- 显式处理
NULL：GROUP BY COALESCE(phone, '<null>')</null>或GROUP BY CASE WHEN phone IS NULL THEN 'UNKNOWN' ELSE phone END - 用
IN子查询时更危险：phone IN (subquery)遇到NULL直接失效，务必加AND phone IS NOT NULL - 想把
NULL当独立类别参与去重：COUNT(DISTINCT COALESCE(phone, '<null>'))</null>
COUNT“统计出重复”的，从来不是函数本身，而是它被放在了不该放的位置——连接没控制、分组没对齐、过滤没分清阶段、空值没兜底。这些地方稍一松动，数字就失真，而且很难一眼看出来。
