在InnoDB中COUNT()与COUNT(1)性能无差异，执行计划相同、耗时相近；COUNT()更安全因符合SQL标准、ORM兼容性好、索引覆盖更稳定；真正影响性能的是WHERE条件、索引选择和事务隔离级别。

MySQL里COUNT(*)和COUNT(1)根本没性能差异

直接说结论：在InnoDB引擎下，COUNT(*)和COUNT(1)执行计划完全一致，耗时几乎相等，差值在毫秒级且无规律——你测十次可能五次COUNT(*)快，五次COUNT(1)快。这不是“基本没差别”，而是MySQL Server层在解析阶段就做了等价替换：COUNT(*)会被优化为COUNT(0)或COUNT(1)，底层走同一套行计数逻辑。

COUNT(*)比COUNT(1)更安全的三个实际原因

虽然性能一样，但COUNT(*)在真实场景中更少出错：

• SQL标准强制要求：COUNT(*)是SQL92定义的唯一标准语法，所有数据库（PostgreSQL、Oracle、SQL Server）都保证语义一致；COUNT(1)只是常见实现，并非标准，某些嵌入式DB或旧版驱动可能不识别
• ORM框架兼容性：MyBatis、SQLAlchemy等默认生成COUNT(*)，硬写COUNT(1)可能触发额外的类型推断或日志告警
• 索引覆盖误判风险：当表有联合索引(a,b)且查询带WHERE a = ?时，COUNT(*)能明确走索引统计行数；而部分MySQL版本对COUNT(1)在复杂WHERE条件下偶发退化为全表扫描（虽罕见，但线上见过）

真正影响COUNT性能的是这三件事

纠结*还是1毫无意义，以下才是拖慢查询的元凶：

• 是否带WHERE条件：无条件COUNT(*)在MyISAM上秒回（元数据缓存），但在InnoDB上必须走聚簇索引或二级索引扫描——数据量千万级时可能达秒级
• 索引选择：如果表有PRIMARY KEY，COUNT(*)会优先用主键索引；若只有UNIQUE索引且字段允许NULL，MySQL可能放弃索引改走全表
• 事务隔离级别：在REPEATABLE READ下，COUNT(*)需构建一致性视图，大表上MVCC开销不可忽略；而COUNT(字段)因要检查NULL值，额外增加字段解码成本

线上大表统计行数的替代方案

当COUNT(*)已慢到无法接受（比如>5s），别再调优写法，该换思路：

• 用SHOW TABLE STATUS LIKE 'table_name'查Rows字段——这是InnoDB估算值，误差通常
• 建专用统计表，每次INSERT/DELETE后用UPDATE stats SET cnt = cnt + 1维护，强一致性场景加SELECT ... FOR UPDATE
• 对超大表分桶采样：SELECT COUNT(*) * 100 FROM t WHERE id % 100 = 0，误差可控且毫秒级返回

真正卡住你的从来不是*和1的微小差异，而是没意识到COUNT本质是I/O密集型操作——它必须触达每一行数据，无论你写什么参数。