count(*) 比 count(列名) 快且结果更可靠，因其跳过字段读取、可选用最窄索引扫描；而 count(列名) 必须取值判空，易引发回表、全行加载及 null 漏计等问题。
COUNT(*) 比 COUNT(列名) 快，不是“有时候快”，而是执行路径根本不同——前者跳过字段读取，后者必须取值判空。
为什么 COUNT(*) 能走最小索引遍历
InnoDB 是索引组织表，优化器对 COUNT(*) 有专用识别逻辑：它知道你只要行数，不关心任何字段内容，于是会主动选择「最窄的可用二级索引」来扫描。比如表上有 INDEX idx_status (status)（TINYINT，1 字节），优化器就宁愿扫它，也不扫主键索引（BIGINT，8 字节），I/O 减少明显。
COUNT(列名) 没这个待遇：server 层明确要那个字段，InnoDB 就得把该字段值从索引或聚簇索引里解析出来——哪怕字段定义为 NOT NULL，也得走一遍取值流程。
- 若该列没索引，InnoDB 只能走聚簇索引，加载整行再提取字段，I/O 放大 5–10 倍（取决于行宽）
- 若该列是
VARCHAR(1000)且只建了前缀索引INDEX idx_name (name(10))，COUNT(name)仍需回表取完整值判空，索引完全失效 - 即使该列类型小、有索引，优化器也只敢用它，不敢换更小的索引——而
COUNT(*)可以自由切换
COUNT(列名) 最容易静默出错的三种情况
它慢只是表象，真正危险的是结果错得毫无提示：
- 字段允许为
NULL：例如COUNT(updated_at)在软删除场景下漏计未更新记录，结果比COUNT(*)少，但查询不报错、无 warning - 字段无索引 + 允许
NULL：触发全行加载，只为判断一个字段是否为空；实测百万行宽表，耗时可能从 20ms 涨到 300ms+ - 字段类型大（如
TEXT或长VARCHAR）且未被索引覆盖：强制回表，延迟放大不可控
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 安全的，它反映的是当前事务一致性视图下的行数；而手写 COUNT(列名) 不仅慢、易错，还可能因字段约束变更（比如后来把 NOT NULL 改成允许 NULL）导致结果静默变化——这种问题上线后极难定位。
