count()统计行数，count(字段)统计该字段非null值；前者只判断行存在性，后者需读取字段值并判空；left join中误用count(字段)会导致语义错误；count()性能通常更优，且与count(1)在主流引擎中等价。
COUNT(*) 统计的是行，COUNT(字段) 统计的是非 NULL 值
这是最根本的语义差异，不是性能问题，而是 SQL 标准强制定义的行为。COUNT(*) 只关心“这一行是否存在”，哪怕 id、name、email 全是 NULL，只要它出现在结果集中，就算 1 行。COUNT(email) 则先取 email 字段值，再判断是否为 NULL；只有非 NULL 值才计入——空字符串 ''、数字 0、布尔 false 全算有效，唯独数据库层面的 NULL 被跳过。
常见错误现象：COUNT(*) 返回 1000，COUNT(email) 返回 823，差值 177 就是 email 列中 NULL 的真实数量。这不是数据丢了，是字段本身允许 NULL 且有 177 条没填。
LEFT JOIN 后用 COUNT(字段) 极易误判主表基数
在 SELECT ... FROM users u LEFT JOIN orders o ON u.id = o.user_id 这类查询里，对右表字段如 o.order_id 使用 COUNT(o.order_id)，统计的是“成功关联的订单行数”，不是“用户数”。1 个用户有 3 笔订单，JOIN 后变成 3 行，COUNT(o.order_id) 就返回 3。
更危险的是：如果 o.user_id 允许 NULL（比如没加 NOT NULL 约束），COUNT(o.user_id) 还会剔除 user_id IS NULL 的行——结果既不是用户总数，也不是订单总数，语义完全错位。
- 想统计左表原始行数，应写
COUNT(DISTINCT u.id) - 想统计右表匹配行数，且该字段已定义
NOT NULL（如主键o.id），COUNT(o.id)才安全 - 用
COUNT(*)配合GROUP BY u.id可清晰看出每组有多少行
COUNT(*) 性能通常优于 COUNT(字段)，尤其字段无索引或 NULL 比例高时
COUNT(*) 只需确认行存在性，优化器常走最小索引（如主键 B+ 树叶子节点）甚至元数据估算；COUNT(email) 必须把 email 列值读出来，再逐行做 IS NOT NULL 判断——哪怕 email 在二级索引里存在，也可能触发回表。
这些隐式开销比函数写法本身影响更大：
- 字段未加
NOT NULL约束 - 该列没有索引
- 表中
NULL占比高（比如日志表里error_code只在出错时有值） - 字段类型是
TEXT或JSON，读取成本高
常见错误现象：给大表加 COUNT(status) 导致查询从 50ms 涨到 2s，换成 COUNT(*) 立刻恢复。
COUNT(*) 和 COUNT(1) 在主流引擎中几乎等价，别为“看起来快”改写
MySQL 8.0+、PostgreSQL、SQL Server 等都会将 COUNT(*) 和 COUNT(1) 优化为相同执行计划。MySQL 官方文档明确说二者处理方式完全相同。所谓“COUNT(1) 只查一列所以更快”，是早期误解——InnoDB 并不会因此少读数据页。
MyISAM 表虽有行数缓存优化，但只有 COUNT(*) 能直接命中；COUNT(1) 需额外判断第一列是否 NOT NULL，反而可能略慢。
真正容易被忽略的地方是：很多人看到老文章说“COUNT(1) 更快”，照搬进新项目，结果既没收益还降低可读性——COUNT(*) 是 SQL92 标准语法，语义最清晰，且现代优化器最熟。
