count(*)与count(1)性能无实质差异，现代数据库优化器将其视为等价操作，均统计所有满足条件的行（含null），执行路径一致；真正影响性能的是索引设计与列是否可空。
别在 COUNT(1) 和 COUNT(*) 之间纠结性能——它们在 MySQL 8.0+、PostgreSQL、SQL Server 等主流数据库中执行计划完全一致，实际耗时差异可忽略。真正影响 COUNT 性能的，是写法背后的语义和索引利用能力。
为什么 COUNT(*) 和 COUNT(1) 基本没区别
两者都统计满足 WHERE 条件的所有行（含 NULL），优化器会统一视作「行存在性计数」，并走相同路径：
- 优先扫描最小的二级索引（例如
KEY idx_status (status)），不回表、不读数据，只遍历索引页计数 - 若无二级索引，则退化为扫描主键 B+ 树的叶子节点（InnoDB 下就是聚簇索引）
-
COUNT(1)并不会“跳过字段读取”而比COUNT(*)快——现代优化器早已把两者等价折叠 - 实测中，同一张千万级 InnoDB 表上，
COUNT(*)与COUNT(1)耗时差值常在 ±0.5ms 内，且受缓冲池命中率影响远大于写法本身
COUNT(列名) 的行为和风险点
它只统计该列值非 NULL 的行，结果可能小于 COUNT(*)，且性能表现高度依赖列定义和索引：
- 若该列有
NOT NULL约束（如主键、自增 ID），COUNT(列名)和COUNT(*)逻辑等价，优化器通常也生成相同执行计划 - 若该列允许
NULL但有二级索引（如INDEX idx_email (email)），MySQL 可能用该索引快速统计——因为 B+ 树索引默认不存NULL，遍历即得非空行数 - 若该列允许
NULL且无索引，优化器必须逐行检查该列是否为NULL，I/O 和 CPU 开销反而可能略高于COUNT(*) - 错误示例：
COUNT(department_id)在一个 70% 字段为NULL的宽表上，可能触发全表扫描 + 列解码，比COUNT(*)慢 20%~40%
让 COUNT 快起来的关键不是换写法，而是建对索引
所有 COUNT 优化最终都落在索引选择上，而不是括号里填什么：
- 确保表有主键（InnoDB 强制要求）；没有主键的 MyISAM 表，
COUNT(*)可能直接查元数据，但这是特例，不可依赖 - 高频 COUNT 场景下，为 WHERE 条件列 + 排序列建联合索引，能让
COUNT(*)走覆盖索引扫描（例如WHERE status = 'active' ORDER BY created_at→ 建INDEX idx_active_time (status, created_at)） - 想靠
COUNT(列名)提速？先确认该列有索引且NULL值极少；否则不如老实用COUNT(*)+ 合适的 WHERE 索引 - 避免在大表上执行无 WHERE 的
COUNT(*)：即使走主键索引，1 亿行也要扫完整棵 B+ 树叶子节点；考虑加缓存或改用近似统计（如TABLE_ROWS从information_schema查，误差可达 40%）
最易被忽略的一点：COUNT(*) 的性能瓶颈从来不在语法糖上，而在是否命中索引、索引是否足够小、以及 WHERE 条件能否被索引覆盖。写成 COUNT(1) 不会让查询变快，但写成 COUNT(email) 却可能因字段可空且无索引而拖慢整条 SQL。
