COUNT()统计所有行（含NULL），COUNT(字段)仅统计该字段非空值；校验字段是否全非空用COUNT()=COUNT(字段)，主键校验必须用COUNT()，LEFT JOIN中COUNT()恒为1而COUNT(右表字段)为0表示无匹配。
COUNT(*) 和 COUNT(字段) 差在哪？校验时别用错
查数据一致性时，COUNT(*) 统所有行（含 NULL），COUNT(字段) 只统计该字段非空值。想确认“某字段是否全有值”，直接写 COUNT(*) = COUNT(字段) —— 返回 TRUE 就说明没漏填。
常见错误：用 COUNT(订单ID) 校验订单总数，结果比实际少——因为有些订单 ID 是 NULL，被自动跳过了。这种脏数据恰恰该被暴露出来。
- 主键/唯一键字段校验，必须用
COUNT(*)，否则漏掉NULL就等于放行违规数据 - 业务上允许
NULL，但只统计“有效值”时，才用COUNT(字段) -
COUNT(*)在LEFT JOIN中始终返回 1（左表行存在），而COUNT(右表字段)返回 0 表示没匹配上
HAVING 才能过滤聚合结果，WHERE 不行
写 WHERE COUNT(*) > 1 会报错，因为 WHERE 运行在分组前，根本看不到聚合值。真正要筛“重复邮箱用户”，得用 HAVING：
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1
注意：HAVING 没索引就慢，如果 GROUP BY 字段（比如 email）没建索引，这个查询可能拖垮整个校验流程。
- 先确认分组字段是否已建索引，尤其是高频校验字段
-
HAVING条件里不能引用未出现在SELECT或GROUP BY中的字段 - 如果只是想排除某类原始行（如
status != 'active'），放在WHERE里更高效
跨表关联一致性怎么查？LEFT JOIN + COUNT 配合用
订单表和订单明细表本该是 1:N 关系，但 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) 而不是 COUNT(*)，前者对空匹配返回 0，后者始终是 1（因为 orders 行还在）。
-
order_items.order_id IS NULL的记录不会参与JOIN，需单独查：SELECT * FROM order_items WHERE order_id IS NULL - 若明细表有复合主键，确保
JOIN条件覆盖全部关联字段，否则漏匹配 - 时间范围不一致也会导致计数偏差，比如明细表加了
WHERE create_time >= '2026-07-01'，但订单表没加，结果必然对不上
整数除法会截断，比例计算必须显式转浮点
做“有效订单占比”这类计算时，COUNT(flag)/COUNT(*) 在 MySQL 或 PostgreSQL 默认返回整数，0.95 直接变 0。SQLite 更隐蔽：10/3 得 3，不是 3.333。
修复方式统一且简单：
- 乘
1.0：ROUND(COUNT(flag) * 1.0 / COUNT(*), 4) - 用
CAST：CAST(COUNT(flag) AS DECIMAL) / COUNT(*) - SQLite 只能写成
COUNT(flag) * 1.0 / COUNT(*)，它不支持DECIMAL类型
聚合结果精度问题往往藏得深——你看到的 0% 或 100%，可能只是整数截断的假象，而不是真实分布。
