COUNT(*)统计所有行，COUNT(字段名)仅统计该字段非NULL行；空字符串和空格不被跳过，需用TRIM+条件判断实现“非空且非空白”统计。
为什么 COUNT(*) 和 COUNT(字段名) 结果不一样
因为 COUNT(*) 统计的是行数，不管字段是否为空；而 COUNT(字段名) 只统计该字段值不为 NULL 的行。这是 SQL 标准行为，不是数据库 Bug。
常见错误现象：用 COUNT(email) 想知道“有多少用户填了邮箱”，结果比预期少——大概率是部分邮箱字段存了空字符串 '' 或空格，但它们不等于 NULL，会被 COUNT(email) 算进去；而真正没填的 NULL 才被跳过。
-
COUNT(*)：返回表总行数（含所有NULL、空字符串、有效值） -
COUNT(col)：只跳过col IS NULL的行，其余全算（包括''、' '、'0'等） - 若想排除空字符串，得显式写：
COUNT(CASE WHEN col != '' AND col IS NOT NULL THEN 1 END)
如何准确统计「非空且非空白」字段数量
很多业务场景下，“非空”实际指“有实质内容”，即既要排除 NULL，也要排除空字符串和纯空白。不同数据库 trim 函数略有差异，但逻辑一致。
以 PostgreSQL / MySQL 8.0+ / SQL Server 为例：
SELECT COUNT(*) AS total, COUNT(name) AS count_name_null_ignored, COUNT(CASE WHEN TRIM(name) != '' THEN 1 END) AS count_name_nonblank FROM users;
-
TRIM(name) != ''同时过滤NULL（因为TRIM(NULL)仍为NULL，不满足!= ''）、空字符串、纯空格 - MySQL 5.7 及更早版本不支持
TRIM多参数，可用TRIM(BOTH ' ' FROM name) - SQLite 用
TRIM(name)即可，但注意它不处理制表符等 Unicode 空白，如有需要需叠加REPLACE
COUNT 配合 GROUP BY 时容易漏掉 NULL 分组
当按某字段分组并统计各组非空数量时，NULL 值会自动聚成一组（或被完全忽略，取决于数据库），但这一组默认没有标签，容易误读。
例如执行：
SELECT status, COUNT(email) FROM orders GROUP BY status;
- 如果
status有NULL，它会单独成一行，status列显示为NULL（不是字符串'NULL'） - 但很多人导出后看不到这行，因为 Excel 或某些客户端默认隐藏
NULL值单元格 - 更稳妥写法是显式标记：
SELECT COALESCE(status, '[unknown]') AS status_grp, COUNT(email) FROM orders GROUP BY COALESCE(status, '[unknown]');
性能影响：COUNT(字段) 在有索引时不一定更快
直觉上以为给字段加索引就能加速 COUNT(字段)，但实际未必。数据库优化器是否走索引，取决于统计信息和字段的 NULL 比例。
- 如果字段
NULL率极高（比如 95%），优化器可能放弃索引，改用顺序扫描——因为跳过大量NULL的成本高于全扫 -
COUNT(*)在 InnoDB 中可直接查聚簇索引行数（近似值），有时反而比COUNT(字段)快得多 - PostgreSQL 中，只有带
NOT NULL约束的字段，COUNT(字段)才可能被优化为等价于COUNT(*)
真要优化统计性能，优先考虑物化统计视图或定时更新的汇总表，而不是依赖 COUNT 实时计算。
