count(*)执行路径最短，因mysql 8.0+ innodb对其有专用优化：server层不构造任何值，innodb仅推进游标累加计数，跳过字段解码；而count(1)需压入常量1并判非空，count(列名)必须取值判null，开销依次递增。
COUNT(*) 为什么在 InnoDB 中执行路径最短
MySQL 8.0+ 的 InnoDB 对 COUNT(*) 有专用识别逻辑：server 层不构造任何值，InnoDB 只需推进游标、累加行计数，连字段解码都跳过。而 COUNT(1) 虽结果一致，但 server 层仍要对每行压入常量 1 再判非空（恒真），多一次栈操作；COUNT(列名) 更得从索引或聚簇索引里取出该列值，再做 IS NOT NULL 判断——哪怕列定义为 NOT NULL，这一步也无法省略。
COUNT(列名) 触发全表扫描的典型条件
只要满足以下任一条件，COUNT(列名) 就很可能放弃索引、加载整行数据：
- 该列允许
NULL且无索引 → 优化器无法跳过判空，只能走聚簇索引逐行读取 - 该列有前缀索引（如
INDEX idx_name (name(10))）→COUNT(name)仍需回表取完整值判空，索引失效 - 该列类型宽（如
VARCHAR(1000)或TEXT）→ 即使有索引，I/O 成本也远高于扫主键索引叶子节点
COUNT(*) 和 COUNT(1) 执行计划真的总一样吗
在绝大多数场景下，二者执行计划相同，但存在隐性偏差风险：
- MySQL 5.7 某些旧版本中，
COUNT(1)曾被误选较宽的二级索引，而COUNT(*)始终倾向最窄索引（如TINYINT索引） - 未执行
ANALYZE TABLE的陈旧统计信息下，COUNT(1)可能触发次优索引选择 -
COUNT(*)是 SQL 标准明确定义“统计行数”的唯一函数，所有主流引擎（MySQL/PostgreSQL/SQL Server）对其做了深度适配，稳定性更高
LEFT JOIN 后 COUNT(列名) 的语义陷阱
在 LEFT JOIN 查询中，COUNT(右表.列名) 不是统计左表行数，而是统计“该列非 NULL 的连接行数”：
- 若右表匹配失败，该列值为
NULL，整行被COUNT跳过 - 若右表一对多（如 1 个用户对应 3 笔订单），
COUNT(orders.id)返回 3，而非用户数 1 - 真正想统计左表原始行数，必须用
COUNT(DISTINCT 左表.id)或子查询，不能依赖任何带列名的COUNT
真正决定快慢的不是括号里填什么，而是该列是否定义了 NOT NULL 约束、有没有针对查询条件建联合索引，以及你是否清楚 COUNT(列名) 统计的从来就不是“总行数”，而是“该列非空行数”。
