COUNT(*)统计的是关联后生成的行数，而非主表行数；用COUNT(从表主键)才能准确统计主表每条记录对应的从表数据量，因主键天然非空。
直接说结论：用 COUNT(*) 统计 JOIN 后的结果，数的不是“主表有多少条”，而是“关联后生成了多少行”；想准确知道“主表每条记录对应多少从表数据”，必须用 COUNT(从表主键) 或 COUNT(非空字段)，且该字段在从表中定义为 NOT NULL。
为什么 COUNT(*) 在 LEFT JOIN 里总 ≥1
LEFT JOIN 会保留左表所有行，即使右表没匹配项，也会补 NULL 值占位——这行依然存在，COUNT(*) 就会把它算进去。结果就是：没订单的用户也显示订单数 = 1。
- 错误写法：
SELECT u.id, COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id→ 所有用户至少为 1 - 正确写法：
SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id→ 没订单用户返回 0 -
o.id是主键，天然NOT NULL，所以COUNT(o.id)只统计真实匹配到的订单行
什么时候不能用 COUNT(从表字段)
如果从表该字段允许 NULL（比如 order_status），那 COUNT(order_status) 会漏掉状态为空的订单——它只跳过 NULL，不跳过空字符串或 'NULL' 字符串。
- 查“有效订单数”但字段可空？先确认业务定义：是“有 ID 的订单”还是“状态不为空的订单”
- 若字段本应非空却存在
NULL，优先修复数据或加约束，而不是靠COUNT补救 - 真要按业务逻辑过滤（如排除
''和'NULL'），得用：COUNT(CASE WHEN order_status IS NOT NULL AND order_status != '' THEN 1 END)
COUNT(DISTINCT 主表.id) 是个危险信号
看到有人用 COUNT(DISTINCT u.id) 来“修正” JOIN 膨胀，说明已经出问题了——这只能掩盖重复，不能定位根源。膨胀通常来自一对多未去重、ON 条件松散、或关联字段含大量重复/NULL。
- 先执行：
SELECT u.id, COUNT(*) cnt FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id HAVING cnt > 1，看哪些用户被复制了 - 再查右表：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT 5，确认是否真有一对多 - 如果发现
user_id有重复值但业务上不该重复，说明数据质量问题，不是 SQL 能修的
最常被忽略的一点：JOIN 后的 COUNT 结果，永远取决于你写的那个字段“在最终结果集里是否为 NULL”，而不是它“在原表里是否为 NULL”。中间经过 ON、WHERE、LEFT/INNER 切换，NULL 的分布早变了——别凭印象猜，用 SELECT * 看几行真实结果，比读十遍文档都管用。
