COUNT(*)统计结果集总行数，COUNT(列名)仅统计该列非NULL值个数；二者差异源于SQL标准对NULL的强制忽略，非bug，只要该列存在NULL值，结果必不相等。
为什么COUNT(*)和COUNT(列名)结果不同
因为 COUNT(*) 统计的是结果集的**总行数**，而 COUNT(列名) 统计的是该列**非 NULL 值的个数**——只要表中存在任意一行该列为 NULL，两者结果就必然不等。这不是 bug，是 SQL 标准强制行为。
COUNT(列名)漏掉的行去哪了
那些被 COUNT(列名) 排除的行，其实都还在结果集中，只是该列值为 NULL。常见来源包括：
- 字段定义允许
NULL，且业务插入时显式写了INSERT ... VALUES (NULL) -
LEFT JOIN后右表无匹配，导致right_table.id为NULL - 默认值设了
'N/A'或0，但约束没加NOT NULL，仍可插入NULL - ETL 过程中未清洗，原始数据带入
NULL
怎么快速确认是不是 NULL 导致的
别猜，直接查差值：
SELECT COUNT(*) AS total, COUNT(email) AS email_non_null, COUNT(*) - COUNT(email) AS null_count FROM users;
如果 null_count > 0，说明 email 列确实有 NULL；此时用 COUNT(email) 就天然少算这些行。注意：''（空字符串）和 0 都会被计入，只有真正的 NULL 被跳过。
关联查询里最容易踩的坑
LEFT JOIN 后直接用 COUNT(*) 或 COUNT(右表列名)，语义完全不同：
-
COUNT(*)→ 数的是连接后“物理行数”，一对多会膨胀 -
COUNT(users.id)→ 只统计右表匹配成功的行，NULL行全被过滤 - 想统计“有多少订单”，不能写
COUNT(*) FROM orders LEFT JOIN users ...，得用COUNT(DISTINCT orders.id)或子查询
最常被忽略的一点：COUNT 的作用对象不是原始表，而是当前执行完 JOIN、WHERE、GROUP BY 后的**中间结果集**——在这个结果集里再判断 NULL，不是在源表里判。
