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%，可能只是整数截断的假象，而不是真实分布。