COUNT(*)是最安全的总行数统计方式，因它统计所有行（含NULL），语义明确、优化器友好；而COUNT(列名)会跳过该列NULL值，结果可能少于实际行数，且依赖列约束可靠性，存在逻辑风险。
COUNT(*) 是最安全的总行数统计方式
为什么不用 COUNT(列名) 统计总记录数
用 COUNT(列名) 会跳过该列值为 NULL 的行，结果不等于实际总行数。比如 COUNT(id) 在 id 允许为空的表里，可能漏掉若干行。
- 只有当明确知道该列定义为
NOT NULL且无任何空值时，COUNT(列名)才等价于总行数 - 但数据库约束可能被绕过（如导入数据、历史遗留），靠人工确认不可靠
-
COUNT(*)明确表示“数所有行”，语义清晰，优化器也更可能走元数据或索引快速路径
COUNT(*) 在不同数据库里的行为是否一致
标准 SQL 要求 COUNT(*) 统计所有行（包括含 NULL 的行），主流数据库（PostgreSQL、MySQL 5.7+、SQL Server、SQLite）都严格遵守。但要注意：
- MySQL 早期 MyISAM 引擎下
COUNT(*)可能直接读取表元数据，极快；InnoDB 则需扫描（除非有覆盖索引） - PostgreSQL 不缓存行数，每次执行都会做顺序扫描或位图扫描，大数据量时可能慢
- 某些只读从库或分库中间件（如 MyCat）对
COUNT(*)的下推支持不完整，可能返回错误结果
想快一点？别只盯着 COUNT(*) 本身
真正影响性能的是执行计划，不是函数写法。优化方向在查询上下文：
- 如果只是检查“是否有数据”，用
EXISTS (SELECT 1 FROM table_name LIMIT 1)更高效，找到第一行就停 - 如果需要近似总数（比如分页总数展示），可查系统表：
SELECT reltuples::BIGINT FROM pg_class WHERE relname = 'table_name'（PostgreSQL）；MySQL 8.0+ 可查information_schema.TABLES中的TABLE_ROWS（注意：InnoDB 该值是估算） - 加
WHERE条件后，COUNT(*)就必须走过滤逻辑，此时索引覆盖程度决定速度——确保过滤字段上有合适索引
很多人卡在“为什么加了索引还慢”，其实问题不在 COUNT 函数，而在是否触发了索引扫描而非全表扫描；而是否能走索引，取决于 WHERE 条件、统计信息准确度和优化器判断——这些比纠结用星号还是列名重要得多。
