COUNT(*)是统计总行数的唯一可靠写法，因其统计结果集所有物理行（含NULL行），而COUNT(列名)仅统计该列非NULL行，语义不同、易致结果偏少且性能更差。
COUNT(*) 是统计总行数的唯一可靠写法，COUNT(列名) 本质是“统计该列非 NULL 行数”，语义不同、性能更差、结果易错——不是“更常用”，而是“必须用”。
为什么 COUNT(*) 不会漏计 NULL 行
COUNT(*) 统计的是满足 WHERE 条件（或全表）的物理行数，完全不检查任何字段内容。哪怕整行所有列都是 NULL，只要它出现在结果集中，就算一个。
COUNT(列名) 则强制跳过该列为 NULL 的所有行，这是 SQL 标准行为，不可关闭、不可绕过。
- 常见错误现象：
COUNT(email)返回 892，COUNT(*)却是 1005 → 说明有 113 行email IS NULL - 软删除场景下，
COUNT(updated_at)会漏掉所有未更新的记录（updated_at IS NULL） - LEFT JOIN 后用
COUNT(right_table.id)，会把没匹配上的左表行全部剔除，结果既不是左表总数，也不是关联成功数
为什么 COUNT(*) 执行更快
MySQL 优化器对 COUNT(*) 有专用识别逻辑：它知道你只要“行存在性”，不需要任何字段值，因此可跳过字段读取，只遍历最窄索引（比如 INDEX idx_status (status)，仅 1 字节），I/O 极小。
COUNT(列名) 没这个待遇：Server 层明确要那个字段，InnoDB 就得从索引或聚簇索引中解析出该列值，再判空。
- 该列无索引 → 强制走聚簇索引，加载整行只为取一个字段，I/O 放大 5–10 倍
- 该列有前缀索引（如
INDEX idx_name (name(10))）→ 仍需回表取完整值判空，索引失效 - 该列允许
NULL且 NULL 占比高（如 60%）→ 二级索引遍历成本反而高于扫主键索引（页更多、结构更宽）
COUNT(*) 和 COUNT(1) 真的等价吗
结果一致，但执行路径不同：COUNT(*) 触发专用优化，Server 层不构造任何值；COUNT(1) 需压入常量 1 再恒真判断，多一次栈操作。
差距在纳秒级，但在以下场景 COUNT(*) 更鲁棒：
- 未执行
ANALYZE TABLE的旧表，某些 MySQL 5.7 早期版本对COUNT(1)误选较大索引，而COUNT(*)从未出现 - 高并发统计压力下，
COUNT(*)的路径更短、更稳定 - 跨数据库迁移时，
COUNT(*)是 SQL92 标准唯一定义“统计行数”的语法，PostgreSQL / SQL Server 都深度适配
什么时候才该用 COUNT(列名)
只有当你**明确需要“该列非 NULL 的数量”**，且已确认业务语义正确时，才用 COUNT(列名)。
使用前务必验证：
- 查
COUNT(*) - COUNT(列名)看 NULL 占比，若 >5%，要考虑加NOT NULL约束或补数据 - 确保该列有覆盖索引（非前缀、非表达式），否则性能损失不可控
- 避免在 JOIN 后直接用，尤其 LEFT JOIN —— 它统计的是“右表该列非 NULL 的连接行数”，不是你想的“左表有效关联数”
真正容易被忽略的，是 NULL 处理的强制性和静默性：它不出错、不报 warning、不提示，只悄悄少算几行——而线上分页、对账、导出都依赖总数准确。
