COUNT()统计所有行（含NULL），COUNT(字段)忽略该字段为NULL的行；校验时用COUNT()=COUNT(字段)可判断字段是否全非空，WHERE不能用聚合函数而HAVING可以，LEFT JOIN中COUNT(字段)与COUNT(*)差异暴露关联问题，整数除法需显式转浮点防截断。
GROUP BY 后 COUNT(*) 和 COUNT(字段) 差在哪？
查重复或缺失时，COUNT(*) 和 COUNT(字段) 返回结果可能完全不同——前者统计行数，后者自动跳过 NULL。比如校验用户订单数，用 COUNT(order_id) 会漏掉 order_id IS NULL 的脏数据，而 COUNT(*) 能暴露它。
- 校验主键/唯一约束是否被破坏，优先用
COUNT(*) - 检查某字段“是否全有值”，用
COUNT(*) = COUNT(字段)是最直接的布尔判断 - 如果字段本身允许
NULL，但业务逻辑要求“非空才参与统计”，才考虑COUNT(字段)
用 HAVING 筛聚合结果，不是 WHERE
WHERE 过滤的是原始行，HAVING 才能过滤分组后的聚合值。想找出“同一邮箱注册了 3 次以上”的用户，写 WHERE COUNT(*) > 3 会报错，必须放 HAVING 里。
- 常见错误：
SELECT user_id, email, COUNT(*) FROM users GROUP BY email WHERE COUNT(*) > 1—— 语法错误，WHERE不认聚合函数 - 正确写法：
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1 -
HAVING会拖慢查询，尤其在没索引的分组字段上，先确认GROUP BY字段是否已建索引
检测跨表关联一致性：LEFT JOIN + COUNT 对不上怎么办
两个表本该 1:N 关联（如 orders ← order_items），但 orders.id 在 order_items.order_id 中出现次数不一致，说明存在孤儿记录或漏关联。
- 典型校验语句：
SELECT o.id, COUNT(oi.id) FROM orders o LEFT JOIN order_items oi ON o.id = oi.order_id GROUP BY o.id HAVING COUNT(oi.id) = 0找出无明细的订单 - 注意
COUNT(oi.id)在LEFT JOIN下对空匹配返回 0，而COUNT(*)仍为 1（因为orders行还在） - 若
order_items.order_id有NULL，它不会和任何orders.id匹配，这类“悬空”记录需单独用WHERE order_id IS NULL检查
聚合结果精度陷阱：整数除法、隐式类型转换
做一致性比例计算（如“有效订单占比”）时，COUNT(valid)/COUNT(*) 在 PostgreSQL 或 MySQL 8.0+ 默认返回整数，结果永远是 0 或 1。
- MySQL 中
SELECT COUNT(flag)/COUNT(*) FROM t若flag全为 1，结果是1；但若实际是0.95，会被截断成0 - 修复方式：显式转浮点，如
ROUND(COUNT(flag)*1.0/COUNT(*), 4)或CAST(COUNT(flag) AS DECIMAL)/COUNT(*) - SQLite 更隐蔽：它没有原生 decimal，
10/3直接得3，必须写成10.0/3
跨库迁移或写通用校验脚本时，这个类型细节最容易被忽略，一查比例全零，还以为数据全坏了。
