COUNT(*)是统计行数的唯一推荐写法，MySQL官方定义其语义为“统计结果集总行数”，5.7至8.4版本均深度优化；COUNT(1)属兼容写法，无优势无背书；COUNT(字段)统计非NULL行，语义不同且性能更差。
count(*) 是统计行数的唯一推荐写法
MySQL 官方明确将 COUNT(*) 作为标准语义“统计结果集总行数”，且从 5.7 到 8.4 所有主流版本都对其做了深度优化：InnoDB 不取任何字段值，只按行遍历聚簇索引或最小二级索引；MyISAM 更直接返回元数据缓存值（无 WHERE 时）。而 COUNT(1) 虽然执行路径几乎一致，但属于“兼容性写法”，既无额外优势，也无标准背书。你写 COUNT(*)，MySQL 就懂你要的是行数——不绕弯、不歧义、不依赖主键是否存在。
count(字段) 会漏算 NULL 行，不是“统计行数”的替代方案
COUNT(字段) 的语义是“该字段非 NULL 的行数”，和“总行数”根本不是一回事。哪怕字段定义为 NOT NULL，优化器也不会自动等价转换——它仍会逐行读取该字段再判断，比 COUNT(*) 多一次字段解析和拷贝开销。常见踩坑场景：
- 误用
COUNT(status)替代COUNT(*)查总数，结果比实际少几十行（status 为 NULL 的记录被跳过） - 在带
WHERE的查询里写COUNT(create_time)，本意是查满足条件的记录数，却因 create_time 允许 NULL 导致结果偏小 - 用
COUNT(id)（id 是主键）自以为更高效，实则比COUNT(*)略慢——引擎要取出 id 值再传给 server 层，而COUNT(*)连这个动作都省了
有 WHERE 条件时，索引决定性能，不是函数选型
当 SQL 带 WHERE（比如 SELECT COUNT(*) FROM orders WHERE user_id = 123），真正影响速度的是能否走索引，而不是写 COUNT(*) 还是 COUNT(1)。此时：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果
user_id有索引，COUNT(*)和COUNT(1)性能完全一致，都是走索引快速定位+计数 - 如果
user_id没索引，全表扫描不可避免，COUNT(*)反而是最优解——它不读字段内容，IO 最轻 -
COUNT(字段)在这种场景下最危险：若字段允许 NULL，引擎必须把每行对应字段值都读出来再判空，比COUNT(*)多一倍数据搬运
别信“count(1) 比 count(*) 快”的过时说法
早期 MySQL 版本（5.5 以前）某些特殊配置下可能有微小差异，但现代 InnoDB 引擎已将 COUNT(*) 和 COUNT(1) 视为同一类语义，执行计划完全一致。你用 EXPLAIN FORMAT=JSON 查看，两者都会显示 "select_type": "SIMPLE", "rows": ..., "filtered": 100.00，没有任何区别。真正拖慢查询的，从来不是多写了星号还是数字 1，而是没加索引、没分析表、或者误用了可空字段统计。
记住一点：只要你想知道“有多少行”，就只用 COUNT(*)。其他写法要么语义错，要么没好处，要么徒增理解成本。
