COUNT(*)在JOIN后统计的是连接后的中间结果行数而非原表行数，易因一对多关系导致重复计数；应据语义选用COUNT(DISTINCT)、COUNT(列)或子查询/CTE规避膨胀。
JOIN后直接用COUNT(*)会得到笛卡尔积结果
很多人一上来就写 SELECT COUNT(*) FROM a JOIN b ON a.id = b.a_id，发现数字远超预期——这不是bug，是SQL语义本身如此。JOIN先生成中间结果集，COUNT(*)数的是这个结果集的行数，不是左表或右表的原始行数。
常见错误现象：COUNT(*)返回几万甚至几十万，而左表其实只有几百条记录；排查时发现右表某条记录匹配了左表多条（比如一个用户有多条订单），导致重复计数。
- 想统计“有多少用户下过单”：该用
COUNT(DISTINCT a.id) - 想统计“有多少订单关联了有效用户”：直接用
COUNT(*)是对的 - 想统计“每个用户对应几条订单”：必须用
GROUP BY a.id，再套COUNT(*)
COUNT(column)和COUNT(*)在JOIN里行为不同
COUNT(*) 统计所有行（包括NULL值参与的行）；COUNT(某列) 只统计该列非NULL的行数。在LEFT JOIN中，这点特别关键。
使用场景：查“哪些用户没下单”，常写 LEFT JOIN orders ON users.id = orders.user_id，然后用 COUNT(orders.id) 判断是否为0。但注意：COUNT(orders.id) 对于NULL值不计数，而 COUNT(*) 仍会计入左表那行。
-
COUNT(*)→ 数的是users表的行数（无论orders是否匹配） -
COUNT(orders.id)→ 数的是匹配成功的订单数（NULL不计） - 若想确认“用户是否存在有效订单”，
COUNT(orders.id) > 0比orders.id IS NOT NULL更安全（避免WHERE提前过滤掉NULL行）
用子查询或CTE避免JOIN膨胀导致COUNT失真
当右表数据量大、且存在一对多关系时，直接JOIN+COUNT容易因中间结果过大拖慢查询，甚至OOM。这时候不该硬扛，要拆开算。
性能影响：MySQL 5.7在JOIN后COUNT(*)可能无法走索引覆盖；PostgreSQL虽优化较好，但大表JOIN仍易触发Hash Join内存溢出。
- 替代方案1（推荐）：
SELECT COUNT(*) FROM users WHERE id IN (SELECT DISTINCT user_id FROM orders)
- 替代方案2（明确语义）：
WITH active_users AS (SELECT DISTINCT user_id FROM orders) SELECT COUNT(*) FROM active_users
- 别用
SELECT COUNT(*) FROM (SELECT DISTINCT ...) t套一层——部分旧版MySQL会丢失索引，优先用CTE或IN
GROUP BY + COUNT配合JOIN时，NULL值要显式处理
LEFT JOIN后做分组统计，如果右表没匹配上，对应字段是NULL，但GROUP BY默认把所有NULL归为一组。这会导致“未匹配的记录全挤在一起”，统计意义错乱。
容易踩的坑：写 GROUP BY orders.status，却发现有个“NULL”组里有上千行——其实是所有没订单的用户都被塞进去了，而不是某个status为NULL的订单。
- 正确做法：用
COALESCE(orders.status, 'no_order')替换NULL，再GROUP BY - 或者更清晰：先过滤出有订单的记录（
WHERE orders.id IS NOT NULL），再按status分组 - 注意：MySQL严格模式下，
SELECT *+ GROUP BY可能报错，务必只选分组字段和聚合字段
