count(*)统计所有行（含全null行），语义最清晰、性能最优且符合sql92标准；count(1)在innodb中与之完全等价；count(字段)仅统计该字段非null值，易因null导致结果偏少。
count(*) 统计的是整行，哪怕所有字段都是 NULL 也计入
这是最根本的语义差异。COUNT(*) 不关心任何字段值，它只数“这一行是否存在”。只要 SELECT 能检索出某一行（哪怕 id、name、email 全是 NULL），就会被计入结果。
COUNT(字段) 则完全不同：它先取该字段的值，再判断是否为 NULL；只有非 NULL 值才参与计数。比如 COUNT(email) 在用户表里可能比 COUNT(*) 少很多——因为部分用户没填邮箱。
- 常见错误现象：
COUNT(*)返回 1000，COUNT(email)返回 823，误以为数据丢了，其实是字段本身有 177 个NULL - 使用场景：统计“已填写手机号的用户数”用
COUNT(phone)；统计“注册总人数”必须用COUNT(*) - 注意：
COUNT(*)是 SQL92 标准语法，所有主流数据库都支持且行为一致；COUNT(字段)的结果依赖该字段定义（是否允许NULL）
count(1) 和 count(*) 在 InnoDB 里完全等价，别信“count(1) 更快”的说法
MySQL 官方文档明确说：SELECT COUNT(*) 和 SELECT COUNT(1) 在 InnoDB 中处理方式相同，性能无差别。所谓“COUNT(1) 只查一列所以更快”，是早期误解——InnoDB 并不会因此少读数据页。
MyISAM 表虽有行数缓存优化，但 COUNT(*) 才能直接命中；COUNT(1) 需额外判断第一列是否 NOT NULL，反而可能略慢。
- 容易踩的坑：看到老文章说“
COUNT(1)比COUNT(*)快”，照搬进新项目，结果既没收益还降低可读性 - 参数差异：
COUNT(1)里的1是常量表达式，不是列名；COUNT(*)的*是唯一合法的通配符参数，其他函数不接受* - 兼容性影响：PostgreSQL、SQL Server、Oracle 对
COUNT(*)同样做了深度优化，而COUNT(1)在某些版本中甚至不被推荐
count(字段) 会触发全表扫描 + NULL 判断，性能通常更差
COUNT(*) 在无 WHERE 条件时，InnoDB 可利用索引快速遍历（如只扫主键 B+ 树叶子节点）；而 COUNT(字段) 必须把每一行对应字段的值读出来，再做 IS NOT NULL 判断——哪怕该字段在二级索引里存在，也可能回表。
尤其当字段类型是 TEXT 或 JSON，或该列允许 NULL 且实际 NULL 比例高时，性能差距更明显。
- 常见错误现象：给大表加
COUNT(status)导致查询从 50ms 涨到 2s，换成COUNT(*)立刻恢复 - 使用场景：仅当你明确需要“该字段非空值数量”时才用
COUNT(字段)；否则一律用COUNT(*) - 例外情况：如果字段上有
NOT NULL约束且是索引列（如主键），COUNT(主键)和COUNT(*)性能接近，但语义已不同——前者仍属COUNT(字段)范畴，不推荐混用
为什么阿里巴巴开发手册强制要求用 count(*)
不是因为它“绝对最快”，而是因为它的语义最清晰、行为最稳定、优化最充分。COUNT(*) 明确表达了“我要总行数”，数据库引擎和 ORM 框架都按此假设做优化；而 COUNT(1) 多一层无意义的常量解析，COUNT(字段) 则引入了隐式的 NULL 过滤逻辑，容易引发业务误判。
真正容易被忽略的点是：很多人以为换用 COUNT(1) 或 COUNT(id) 是“微优化”，却没意识到它悄悄改变了语义边界——一旦字段约束变更（比如 id 字段某天允许 NULL），COUNT(id) 结果就会突变，而 COUNT(*) 始终可靠。
