COUNT(*)统计JOIN后膨胀行数，COUNT(列名)仅统计该列非NULL的膨胀行；二者基数不同，不可混用。
LEFT JOIN后COUNT(*)和COUNT(列名)统计对象根本不同
很多人以为COUNT(*)和COUNT(右表.列名)只是“是否算NULL”的差别，其实它们的统计基数已经不同：前者数的是JOIN后的所有行（含左表一行被撑开成N行的情况），后者只在这些膨胀后的行里筛非NULL值。比如左表100行、右表对每个左表ID平均有3条匹配记录，JOIN后就有300行，COUNT(*)返回300，而COUNT(右表.id)最多也是300——但若其中有NULL（比如RIGHT JOIN写错成LEFT），它还会进一步缩水。
常见错误现象：COUNT(*)远大于左表原始行数，而COUNT(右表.status)又明显小于COUNT(*)，说明既发生了行膨胀，又存在右表字段为NULL的匹配失败。
- 先验证膨胀：单独执行
SELECT COUNT(*) FROM 左表，再执行完整LEFT JOIN加COUNT(*)对比 - 别用
COUNT(右表.列名)代替“左表有效记录数”——它统计的是“成功关联且该列非NULL”的行，不是左表本身 - 真要统计左表有多少条，就用
COUNT(DISTINCT 左表主键)，前提是GROUP BY里包含该主键
多个LEFT JOIN叠加时COUNT虚高是乘法级的
两个LEFT JOIN串在一起，不是简单相加，而是行数相乘。例如订单表LEFT JOIN订单明细表（1:5），再LEFT JOIN用户地址表（1:2），那么一条订单可能生成5×2=10行。此时COUNT(*)是10，COUNT(明细.id)是5（因为每条明细重复了2次），COUNT(地址.id)是2（因为每个地址重复了5次）——三个COUNT全失真。
使用场景：报表中同时展示“每单总金额”和“每单收货地址数”，如果直接三表LEFT JOIN后SUM(明细.amount)和COUNT(地址.id)，结果必然翻倍。
- 解法不是在最后加
DISTINCT，那只会去重最终结果，不阻止中间膨胀 - 必须拆开聚合：分别用子查询按
order_id预计算SUM(amount)和COUNT(*)，再LEFT JOIN回主表 - MySQL 8.0+可用CTE，PostgreSQL可考虑
LATERAL，避免重复扫描大表
WHERE里过滤右表字段会让LEFT JOIN退化成INNER JOIN
这是最隐蔽也最高频的偏差来源。WHERE 右表.字段 = 'X'会把所有右表不匹配（即该字段为NULL）的左表行整个踢掉，等效于INNER JOIN。此时COUNT(*)变小，但你以为是LEFT JOIN，实际已丢失左表数据。
错误示例：LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active' → 所有无用户或用户非active的订单都不见了。
- 正确做法是把条件挪进
ON：LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active' - 注意：部分旧版SQLite或某些ODBC驱动对
ON里的复杂条件支持不好，上线前务必实测 - 如果业务上真需要“全部订单 + 其中active用户的统计”，就得用子查询或
CASE WHEN聚合，不能靠WHERE救场
COUNT在多表JOIN中真正可靠的写法只有两种
要么彻底规避膨胀，要么承认膨胀并明确统计意图。不存在“一个COUNT通吃所有场景”的写法。
性能影响：子查询预聚合虽然写法稍长，但通常比裸JOIN快得多——数据库不用构造百万行中间结果，内存和IO压力直线下降；而EXISTS替代LEFT JOIN在仅需布尔判断时更轻量，但无法带回右表字段。
- 要“每个左表记录对应多少条右表数据”：用
(SELECT COUNT(*) FROM 右表 WHERE 右表.key = 左表.key)相关子查询 - 要“左表某字段的汇总值（如SUM）”：用
(SELECT SUM(val) FROM 右表 WHERE ...)，而非JOIN后SUM - 如果右表数据量极大，给
WHERE条件字段建联合索引，否则子查询也会慢
SELECT *看几行真实结果，比盯着COUNT数字猜原因快十倍。 
