count()与count(1)语义和性能完全等价，均统计所有满足条件的行（含null），执行路径一致、无性能差异；推荐优先使用count()因其符合sql标准、跨数据库兼容性好、语义更清晰。
count(*) 和 count(1) 在现代数据库里基本没区别
绝大多数主流数据库（MySQL 8.0+、PostgreSQL、SQL Server、Oracle）的查询优化器会把 COUNT(1) 和 COUNT(*) 视为等价操作，最终生成完全相同的执行计划。这不是“凑巧”，而是 SQL 标准语义和优化器长期演进的结果：COUNT(*) 明确表示“统计行数”，而 COUNT(1) 中的 1 是非空常量，每行必计，逻辑上等同于行计数。
所以如果你看到某篇老文章说“COUNT(1) 比 COUNT(*) 快”，大概率是基于以下情况之一：
- 使用了非常早期的 MySQL 版本（如 5.5 或更早），且未开启优化器增强
- 测试时恰好命中了缓存或统计信息偏差，误判了耗时
- 对比的是
COUNT(col)而非COUNT(*)，混淆了 NULL 判断开销
真正影响 COUNT 性能的关键是列是否可空
COUNT(column) 的性能差异不来自“写法”，而来自语义：它必须逐行检查该列是否为 NULL。哪怕这个列上有索引，只要不是 NOT NULL 约束，优化器就无法跳过 NULL 判断。
常见陷阱包括：
-
COUNT(department_id)—— 如果该字段允许 NULL，即使有索引，也可能触发回表或全索引扫描 -
COUNT(*) WHERE status = 'active'—— 条件过滤后，优化器可能选择走二级索引 + 聚簇索引查找，比直接扫主键还慢 - 在无主键的堆表（如 MySQL MyISAM 或某些归档表）上，
COUNT(*)可能退化为全表扫描，此时COUNT(1)并不能改善
什么时候 count(1) 真的比 count(*) 快？极少数例外场景
这类情况现在极少出现，但需知道边界：
- MySQL 使用 MyISAM 引擎且表无主键：MyISAM 维护了行数元数据，
COUNT(*)可直接返回；但若写了COUNT(1)，旧版本优化器可能误判为需要扫描——注意，这是 bug 级行为，不是设计优势 - 某些嵌入式或轻量级数据库（如 SQLite 3.20 之前）未对
COUNT(*)做特殊优化，而把COUNT(1)当作常量表达式提前折叠 - ORM 自动生成语句时强制拼
COUNT(1)，恰好绕过了某个 ORM 对COUNT(*)的解析 Bug（例如早期 Hibernate 对 HQL 的处理）
这些都不是你应该主动依赖的优化点，而是兼容性补丁或历史包袱。
想让 COUNT 快，别纠结 1 还是 *，盯紧三件事
实际调优中，95% 的慢 COUNT 问题跟写法无关，而和这三点强相关：
- 确保被统计的表有明确主键（最好是自增整型），让优化器能用最小索引（如主键 B+ 树的叶子节点数）估算或精确计数
- 避免在大表上执行无条件
COUNT(*)—— 改用近似值（如 PostgreSQL 的pg_class.reltuples，MySQL 的INFORMATION_SCHEMA.TABLES）或加缓存层 - 如果必须精确统计带条件的行数，优先给
WHERE字段建联合索引，并确认该索引能覆盖COUNT所需的所有列（避免回表）
最常被忽略的一点：很多 DBA 以为加个索引就能加速 COUNT(col)，但如果 col 允许 NULL，索引里就不存这些记录，结果直接不准——COUNT(col) 不是“数索引行数”，而是“数非 NULL 行数”，这两者在索引结构里根本不是一回事。
