在innodb中count()与count(1)执行计划完全一致，优化器均跳过字段读取、只遍历最小索引计数；count()是sql标准写法，语义明确且跨库兼容性更好，推荐优先使用。
MySQL里COUNT(*)和COUNT(1)真的没区别吗
在InnoDB表中，COUNT(*)和COUNT(1)执行计划完全一致，优化器会跳过字段读取，只遍历索引叶子节点计数。MyISAM表下COUNT(*)可能直接读元数据，而COUNT(1)需确认第一列是否为NOT NULL——但绝大多数线上系统用的是InnoDB，所以你写哪个都一样。
什么时候COUNT(1)反而比COUNT(*)慢
常见错误现象：COUNT(1)在已做ANALYZE TABLE的表上耗时略高（尤其小表），因为优化器多了一次常量表达式解析；而COUNT(*)被识别为语义明确的行数统计，路径更短。这不是性能bug，是优化器分支判断的微小开销。
- 表只有1万行以内且频繁执行
ANALYZE时，差异可达5%～10%，但绝对值通常在毫秒级 - 如果误把
COUNT(1)写成COUNT(0)，某些旧版MySQL（5.6之前）会触发全表扫描——0被当作可为空表达式处理 - 别信“
COUNT(1)避免了*的解析开销”这种说法：现代SQL解析器对*有专用快速路径，比解析数字常量还轻量
COUNT(*)在LEFT JOIN中怎么不被右表NULL拖累
关键点在于：它统计的是结果集的行数，不是左表原始行数。比如SELECT COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id，若某用户无订单，JOIN后仍生成1行（o.*全为NULL），这行仍被COUNT(*)计入。想统计用户数？得加GROUP BY u.id再套一层，或改用COUNT(DISTINCT u.id)。
- 误用
COUNT(o.id)会漏掉无订单用户——因为o.id为NULL时不计数 -
COUNT(*)在此场景下语义清晰，但别指望它自动“去重”或“还原主表基数” - 如果右表字段有NOT NULL约束（如
o.id为主键），COUNT(o.id)才等价于匹配行数，而非用户总数
为什么阿里开发手册强制要求用COUNT(*)
不是因为性能，而是语义确定性。COUNT(1)在标准SQL中属于“非标写法”，虽然主流数据库都支持，但Oracle早期版本对COUNT(1)的优化不如COUNT(*)稳定；PostgreSQL 12之前，COUNT(1)在某些窗口函数嵌套场景下会产生意外空值。用COUNT(*)能规避这些边界问题，且团队协作时一眼可知意图。
真正容易被忽略的点是：当查询带WHERE条件且字段无索引时，COUNT(*)和COUNT(1)都会触发全表扫描——此时纠结二者差异毫无意义，该建索引就建索引，而不是换函数名。
