为什么SQL中COUNT(常量)和COUNT(1)没有性能差异？

优化器在语义分析阶段就识别出所有非NULL常量（比如1、42、'x'）都不依赖列值，逻辑上等价于“每行必计1次”，直接统一归一化为行计数操作。MySQL 8.0+、PostgreSQL 14+ 等会把COUNT(1)和COUNT('hello')都重写成内部的COUNT(*)表示，后续走完全相同的索引扫描路径。

为什么COUNT(1)和COUNT(42)执行计划完全一样？

因为优化器在语义分析阶段就识别出所有非NULL常量（1、42、'x'）都不依赖列值，逻辑上等价于“每行必计1次”，直接统一归一化为行计数操作。MySQL 8.0+、PostgreSQL 14+ 等会把COUNT(1)和COUNT('hello')都重写成内部的COUNT(*)表示，后续走完全相同的索引扫描路径。

EXPLAIN 显示 type=index、Extra=Using index 是什么信号？

这说明数据库没读数据行，只遍历了最小可用索引的叶子节点——无论你写COUNT(*)还是COUNT(1)，只要表有主键或二级索引，优化器就会选key_len最小的那个索引快速计数。真正耗时的是I/O扫描页数，不是括号里填啥。

• 有主键 → 通常扫聚簇索引（B+树叶子节点）
• 只有INDEX idx_status(status) → 可能扫这个二级索引（比主键窄）
• 无索引 → 两者都退化为全表扫描，开销相同

为什么 COUNT(id) 反而可能更慢？

COUNT(id)不是常量，它是列引用。哪怕id是主键且NOT NULL，优化器也得把每个id值从索引页中解包、传给Server层做NULL判断——多了内存拷贝和类型处理。而COUNT(*)和COUNT(1)完全跳过字段读取，纯计页。

• 如果id允许NULL，必须逐行检查，无法跳过
• 如果email字段允许NULL且无索引，COUNT(email)会触发全表扫描 + 每行判NULL，比COUNT(*)慢数倍
• COUNT(*) WHERE status = 'active'若命中二级索引，可能比COUNT(status)还快——因为后者仍要过滤NULL

别被“COUNT(1)更快”的老文档带偏

那些说法基本来自三类已失效场景：MySQL 5.5以前MyISAM引擎的元数据缓存bug；SQLite 3.20前未对COUNT(*)做常量折叠；或者ORM自动生成语句时绕过某个解析限制。现代数据库里，COUNT(1)唯一真实开销是Server层多一次常量表达式解析——纳秒级，不可测，也不该成为决策依据。

真正该盯紧的，是表有没有主键、WHERE条件能否走覆盖索引、以及你到底需要“总行数”还是“某列非空行数”。后者才是影响结果和性能的硬边界。