COUNT(*)统计所有行（含NULL），COUNT(字段)仅统计该字段非NULL值；误用后者统计总数会导致结果偏少，如100行中13个email为NULL时COUNT(email)返回87。
COUNT(*) 和 COUNT(字段) 的行为差异必须分清
直接写 COUNT(*) 会统计所有行（包括含 NULL 的行），而 COUNT(列名) 只统计该列非 NULL 的值。如果误用 COUNT(email) 统计用户总数，但部分用户 email 为空，结果就会少于实际注册人数。
常见错误现象：明明查出 100 条记录，COUNT(email) 却返回 87 —— 这不是函数出错，是数据本身有 13 条 email IS NULL。
- 统计总行数、含空值的行，一律用
COUNT(*) - 统计某字段“有效填写量”（如已验证手机号数），才用
COUNT(phone) - 想统计去重数量？别套
COUNT(DISTINCT email)就完事，注意 MySQL 5.7+ 支持，但旧版不支持该语法
WHERE 条件必须写在 COUNT 外部，不能塞进函数里
COUNT 是聚合函数，它不接收条件表达式作为参数。写成 COUNT(status = 'active') 在 PostgreSQL 里会返回 0 或 1 的计数（因布尔值被转为整数），但在 MySQL 中可能报错或语义混乱；这不是标准用法，也极易引发跨库迁移问题。
正确做法永远是把过滤逻辑放在 WHERE 子句：
SELECT COUNT(*) FROM users WHERE status = 'active';
如果真要一条 SQL 里统计多个状态的数量（比如同时要 active、inactive、pending 各多少），就用条件聚合：
SELECT COUNT(CASE WHEN status = 'active' THEN 1 END) AS active_count, COUNT(CASE WHEN status = 'inactive' THEN 1 END) AS inactive_count FROM users;
GROUP BY 配合 COUNT 容易漏掉空组或 NULL 分组
当按 category 分组统计商品数时，如果某些分类在表中完全不存在（比如数据库里没存 “accessories” 类别），GROUP BY category 就不会输出这一行 —— COUNT 不会“补零”。同样，若 category 有 NULL 值，它们会被归为同一组，但容易被忽略。
- 需要确保所有预期分类都出现？得用左连接配合维表，或用
UNION ALL手动补缺 - 检查
NULL分组是否存在：GROUP BY COALESCE(category, '[unknown]')或显式加WHERE category IS NOT NULL - MySQL 中
sql_mode含ONLY_FULL_GROUP_BY时，SELECT id, COUNT(*) FROM t GROUP BY category会报错 —— 因为id不在GROUP BY列表也不含聚合函数
性能敏感场景下 COUNT(*) 并不总是最慢的
很多人听说“COUNT(*) 要扫全表所以慢”，就改用 COUNT(id) 以为能走索引加速。实际上，在 InnoDB 中，COUNT(*) 优化器通常会选择最小的非空索引（比如主键）遍历，和 COUNT(pk) 性能几乎一致；而 COUNT(普通字段) 反而可能被迫回表或无法利用覆盖索引。
- 确认执行计划：
EXPLAIN SELECT COUNT(*) FROM orders WHERE created_at > '2024-01-01'; - 大表无 WHERE 条件时，
COUNT(*)在 MySQL 8.0+ 可能利用采样估算（需开启innodb_stats_method=sample），但生产环境慎用，误差不可控 - 真要高频查总数且允许轻微延迟？考虑用缓存字段（如
stats.total_users）或物化视图（PostgreSQL）
COUNT 当成万能过滤工具，或者默认它“知道你要什么”。它只数行、数非空值、数去重值——别的都不管。要不要 NULL、要不要分组、要不要精确值，全靠你写的 WHERE、GROUP BY 和函数选型决定。 
