COUNT(列名)比COUNT()和COUNT(1)慢，因其必须逐行取值并判断非NULL；COUNT(1)最快，因仅计行数无需取值；COUNT()优化器选最小索引，性能接近COUNT(1)；WHERE条件才是性能瓶颈。
MySQL执行COUNT(列名)时必须检查NULL值
因为COUNT(expr)的语义是“统计expr不为NULL的行数”，当expr是具体列名（如age、email）时，InnoDB每读取一行，server层必须拿到该列的实际值，再做一次IS NOT NULL判断。这个判断无法跳过，哪怕该列有索引或定义了NOT NULL约束——优化器仍需确保语义正确，尤其在存在触发器、生成列或MVCC快照差异时。
常见错误现象：COUNT(email)在email字段大量为NULL时，执行时间明显长于COUNT(*)，且EXPLAIN显示实际扫描行数与结果行数差距大，说明确实在逐行判空。
- 如果列上有
NOT NULL约束，优化器可能省略判空步骤，但并非所有版本都稳定启用该优化 - 如果列是
TEXT或JSON类型，即使非空，取值开销也比整型列高得多 -
COUNT(列名)无法利用“最小索引树”优化，它倾向走聚簇索引或该列的二级索引（若存在），但最终仍需回表取值判空（除非是覆盖索引且列本身非空）
COUNT(1)无需取字段值，只计数
COUNT(1)中的1是常量表达式，InnoDB在遍历索引时，server层只要收到“这一行存在”，就直接对计数器+1，完全不需要访问任何字段数据。这意味着：
- 执行路径跳过了字段读取、类型转换、NULL判断三步
- 优化器可自由选择代价最小的索引（通常是主键或最窄的二级索引）进行扫表
- 即使表有100个字段，
COUNT(1)的I/O和CPU开销也基本恒定
注意：MyISAM下COUNT(1)能否享受行数缓存，取决于第一列是否定义为NOT NULL；而InnoDB下它和COUNT(*)走完全相同的执行引擎路径，官方文档明确说二者“handled in the same way”。
为什么COUNT(*)能比COUNT(列名)快，却不一定比COUNT(1)快
表面上看COUNT(*)要“查所有列”，其实恰恰相反：MySQL优化器知道*不涉及具体字段值，会主动选择空间最小的可用索引（比如一个只有id的二级索引），仅靠索引页就能完成计数，连聚簇索引都不用碰。而COUNT(列名)若该列无索引，或索引不是覆盖的，就会被迫回表——这才是性能分水岭。
至于COUNT(*)和COUNT(1)的微小差异，只出现在极少数场景：
- 表刚
ANALYZE TABLE后，某些旧版本MySQL可能对COUNT(1)使用更激进的索引采样（但不可靠） - 存在虚拟生成列且依赖被统计列时，
COUNT(列名)可能触发额外计算，而COUNT(1)完全免疫 -
COUNT(*)在MySQL 8.0.13+对无条件单表查询做了批处理优化，COUNT(1)同步受益，两者实际耗时差通常在毫秒级以内
容易忽略的关键点：WHERE子句让所有COUNT行为归零
无论你写COUNT(*)、COUNT(1)还是COUNT(status)，只要带WHERE条件，前面所有索引选择、NULL判断、常量优化全部失效。InnoDB必须走满足WHERE的执行计划（可能是索引范围扫描+回表，也可能是全表扫描），然后对每一行结果再做对应COUNT逻辑。此时性能瓶颈从来不在COUNT本身，而在WHERE能否命中高效索引。
换句话说：纠结COUNT(列名)慢，不如先看EXPLAIN里type是不是ALL、key是不是NULL。真正的性能杀手，永远藏在条件过滤那一步。
