没有性能差别；在InnoDB中COUNT(*)与COUNT(1)执行计划完全一致、耗时相近，优化器会等价替换，真正影响性能的是WHERE条件、索引选择和MVCC可见性判断。
MySQL里COUNT(1)和COUNT(*)真有性能差别吗
没有。在绝大多数场景下，COUNT(*) 和 COUNT(1) 执行计划完全一致，优化器会把它们都等价转换为“统计表的行数”，不读取具体字段值，也不触发NULL判断逻辑。
常见错误现象是看到慢查询日志里 COUNT(1) 耗时高，就以为换 COUNT(*) 能提速——其实两者耗时几乎一样，真正瓶颈往往在是否走索引、是否需要扫描全表、MVCC可见性判断开销上。
使用场景上：COUNT(*) 是SQL标准写法，语义清晰（统计所有行）；COUNT(1) 是历史习惯，某些老开发误以为“传个常量比 * 快”，但MySQL从5.5起就做了等价优化。
什么时候COUNT(*)会变慢，跟写法无关
真正影响速度的是查询条件和表结构，不是括号里写什么：
- 没WHERE条件且表无主键/无二级索引：InnoDB必须遍历聚簇索引（即整张表），行数越多越慢
- 带WHERE但条件无法利用索引：同样退化为全表扫描
- 大表上执行时并发事务多：MVCC需要逐行判断可见性，即使只统计行数，也可能被其他长事务拖慢
- 使用MyISAM引擎：虽然
COUNT(*)快（直接读元数据），但COUNT(1)也一样快——因为MyISAM根本不关心括号里是什么
COUNT(column)和COUNT(*)行为完全不同
这是最容易混淆的点：COUNT(*) 统计所有行，COUNT(column) 只统计该列非NULL的行数。
例如：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
SELECT COUNT(*), COUNT(1), COUNT(name) FROM users;
如果name字段有3行是NULL，则COUNT(name)结果比前两者少3。而COUNT(*)和COUNT(1)始终相等。
注意：COUNT(1)里的1是常量表达式，不是列名，所以它不会判NULL，效果等同COUNT(*)。
别在COUNT里写表达式，比如COUNT(id+0)
只要括号里不是常量或*，优化器就可能放弃优化路径：
-
COUNT(id)→ 统计id非NULL行数（如果id是主键则等价COUNT(*)，但优化器不一定能推断出来） -
COUNT(IF(id>0,1,NULL))或COUNT(id+0)→ 强制逐行计算表达式，无法走优化路径，性能明显下降 -
COUNT(DISTINCT column)→ 必须去重，用临时表或排序，和普通COUNT(*)完全不是同一量级
想确认实际执行方式，一定看EXPLAIN输出：如果type是index或ALL，说明在扫索引/表；如果rows接近表总行数，那不管写COUNT(*)还是COUNT(1)都得忍着。
