count(*)比count(列名)更轻量，因其仅需确认行存在，可直接遍历最小索引（如主键b+树叶子节点），无需读取字段值；而count(列名)必须加载该列实际值并逐行判空，无法跳过取值过程。
为什么COUNT(*)比COUNT(列名)执行路径更轻量
COUNT(*)只需确认“行是否存在”，数据库优化器可直接遍历最小索引（如主键B+树叶子节点），不读取任何字段值；而COUNT(列名)必须把该列实际值从磁盘或缓冲池中加载出来，再逐行判断是否为NULL——这个取值 + 判空过程无法跳过。
现代引擎（MySQL 8.0+ InnoDB、PostgreSQL）对COUNT(*)有专用识别逻辑：COUNT(1)虽语义等价，但server层仍需压入常量并做一次恒真判断；COUNT(列名)则完全失去索引自由选择权，哪怕该列有索引，也得按定义去取值。
- 无索引 + 允许
NULL→ 必触发全表扫描，加载整行只为判一个字段 - 列类型宽（如
VARCHAR(1000)）→ 即使有前缀索引，仍要回表取完整值 - 索引存在但
NULL占比高（>50%）→ 二级索引页更多、遍历成本反超主键索引
COUNT(列名)的性能陷阱常藏在隐式约束里
很多人写COUNT(email)时默认它“应该快”，却没检查email字段是否加了NOT NULL约束。只要没加，优化器就必须判空；哪怕99%的值非空，剩下的1%也迫使它走最保守路径。
更隐蔽的是：即使email有索引，若该索引是INDEX idx_email (email(10))（前缀索引），COUNT(email)也无法用索引覆盖，因为前缀不保证全值唯一性，仍需回表取完整email再判空。
- 查约束：
SHOW COLUMNS FROM users LIKE 'email';看Null列是否为YES - 查索引覆盖：
EXPLAIN SELECT COUNT(email) FROM users;看key和Extra是否含Using index - 别信“字段小就快”：
TINYINT列若允许NULL且无索引，照样比COUNT(*)慢
LEFT JOIN后COUNT(列名)不仅慢，还静默错
在SELECT COUNT(*) FROM orders LEFT JOIN users ON orders.user_id = users.id里，COUNT(*)统计的是连接后物理行数（可能因一对多膨胀）；而COUNT(users.id)会剔除所有users.id IS NULL的行——结果既不是订单数，也不是用户数，而是“成功关联的订单数”。
这个错误不会报错、不抛warning，但性能上更糟：右表字段在LEFT JOIN后多数为NULL，COUNT(users.id)要对每行做一次IS NOT NULL判断，且无法利用左表索引加速。
- 想统计原始订单数 → 用
COUNT(DISTINCT orders.id)或子查询 - 想统计关联成功的用户数 → 明确写
COUNT(users.id)，但得接受它天然漏掉NULL行 -
COUNT(*)在JOIN后语义模糊，但至少执行路径稳定；COUNT(列名)在此场景下纯属双重风险
真正该盯住的不是函数写法，而是NULL和索引
COUNT(*)和COUNT(1)在主流引擎中执行计划几乎一致，耗时差异通常在±0.5ms内；而COUNT(列名)的性能波动，主要来自三个可验证事实：该列是否定义<code>NOT NULL、WHERE条件是否有对应联合索引、以及业务是否真需要“非空计数”本身。
如果发现COUNT(*) - COUNT(列名)差值很大，先别急着换写法——查下NULL占比：SELECT COUNT(*) - COUNT(email) AS null_count FROM users;。若null_count > 0，说明你根本不是在优化查询，而是在用错误口径统计。
最常被忽略的一点：NULL处理发生在WHERE和GROUP BY之后，COUNT(列名)反映的是当前中间结果集里的非空数量，不是原始表分布。复杂查询里一旦混淆这点，指标偏差不会报警，只会安静地错下去。
