COUNT(*)比COUNT(列名)快，因其无需读取字段值、可走最小索引遍历，而后者必须逐行取值判空，可能触发回表或全行解析，I/O开销更大。
COUNT(*) 比 COUNT(列名) 快，不是“差不多快”，而是有明确的执行路径差异——前者能跳过字段读取，后者必须取值判空。
为什么 COUNT(*) 能走最小索引遍历
InnoDB 是索引组织表，聚簇索引（主键索引）叶子节点存整行数据，而二级索引叶子节点只存主键值。COUNT(*) 不需要任何字段内容，优化器会主动选择「最窄的可用索引」来遍历，比如一个只有 status 的二级索引（单字节 TINYINT），比扫描主键索引（8 字节 BIGINT）I/O 更少。这个选择是优化器在 server 层做的语义决策，COUNT(*) 是唯一被明确识别为“纯行数统计”的语法。
而 COUNT(列名) 无法享受该优化：server 层指定了要那个字段，InnoDB 就得把该字段值拿出来——哪怕字段定义为 NOT NULL，也得从索引或聚簇索引中解析出它；若字段没索引、类型大（如 TEXT）、或索引不覆盖，就会触发回表，整行加载。
COUNT(列名) 最容易静默出错的三种情况
- 字段允许为
NULL：例如COUNT(updated_at)在软删除场景下漏计未更新的记录，结果比COUNT(*)少，且无报错、无提示 - 字段无索引 + 允许 NULL：InnoDB 只能走聚簇索引，逐行读取整行再提取该字段判断是否为空，I/O 放大 5–10 倍（取决于行宽）
- 字段类型大但建了前缀索引：比如
VARCHAR(1000)建了INDEX idx_name (name(10))，COUNT(name)仍需回表取完整值判空，索引形同虚设
COUNT(*) 和 COUNT(1) 真的等价吗
逻辑结果一致，但执行细节不同：COUNT(*) 触发专用优化路径，server 层不构造任何值，InnoDB 只需推进游标并累加；COUNT(1) 虽也不取字段，但 server 层对每行硬塞一个常量 1 再判非空——多一次常量压栈和判断动作。差距极小（纳秒级），但在高并发统计或未 ANALYZE TABLE 的旧表上，COUNT(*) 更稳定。某些 MySQL 5.7 早期版本甚至对 COUNT(1) 误选较大索引，而 COUNT(*) 从未出现这类偏差。
别为了“理论上更快”去用 COUNT(主键)
有人看到执行计划里 key=PRIMARY 就认为 COUNT(id) 最优，其实危险：COUNT(id) 仍需从主键索引叶子节点取出每个 id 值传给 server 层，而 COUNT(*) 连这个取值动作都省了。实测百万行表，二者耗时差通常 WHERE 条件或涉及分区表，COUNT(id) 可能失去索引选择优势，COUNT(*) 反而更鲁棒。真正影响性能的是有没有 WHERE、索引覆盖度、MVCC 快照大小，不是括号里写什么。
最易被忽略的一点：COUNT(*) 的行为在 InnoDB 中是 MVCC 安全的，它反映的是当前事务一致性视图下的行数；而你若手动维护一个计数器字段，就再也无法自动适配事务隔离级别变化——这个隐性成本，远高于那零点几毫秒的执行差异。
