count(列名) 总是 ≤ count(*)，因为前者仅统计该列非null的行，后者统计所有物理行；差值即该列null数量，这是sql标准强制行为，非bug。
COUNT(列名) 和 COUNT(*) 不一致，不是 bug，是 SQL 标准强制要求的行为：前者只数该列非 NULL 的行，后者数所有行。
为什么 COUNT(列名) 总是 ≤ COUNT(*)
COUNT(*) 统计的是结果集的物理行数，不管任何列是否为 NULL；COUNT(列名) 则逐行检查该列值 —— 只要 列名 IS NULL，这一行就跳过。所以差值就是该列 NULL 的数量。
- 常见现象：
COUNT(id)返回 98，COUNT(*)返回 100 → 说明有 2 行的id是 NULL（哪怕它是主键字段，只要没加NOT NULL约束，就可能存 NULL） -
''（空字符串）、0、false都算非 NULL，会被COUNT(列名)计入；只有真正的NULL被跳过 -
COUNT(*) - COUNT(列名)是验证该列 NULL 数量最直接的方式，比查表结构或猜业务逻辑更可靠
COUNT(列名) 在 LEFT JOIN 后容易误用
LEFT JOIN 会让右表字段在匹配失败时变成 NULL，这时 COUNT(右表.列名) 实际统计的是“成功关联的行数”，而不是左表原始行数。
- 例如：
SELECT COUNT(*) FROM orders LEFT JOIN users ON orders.user_id = users.id→ 结果是连接后总行数，可能因一对多而膨胀 - 而
COUNT(users.id)会把所有users.id IS NULL的行排除，结果可能远小于左表订单数 - 真正想统计“有多少订单”，应写
COUNT(DISTINCT orders.id)或改用子查询，不能依赖位置或函数选择
性能差异真实存在，但常被高估
差别主要来自是否需要判空和索引利用路径，不是“哪个更快”的简单问题。
-
COUNT(*)在无WHERE时，MySQL InnoDB 8.0+ 可能走元数据估算或最小索引扫描，开销极小 -
COUNT(列名)必须读取该列实际值判断是否为 NULL；若该列无索引，大概率触发全表扫描 - 即使该列有索引，若允许 NULL，优化器仍需确认每条索引项对应行是否真实存在（避免幻读），无法完全跳过回表
-
COUNT(1)和COUNT(*)在现代数据库中执行计划几乎一致，别为了“看起来快”刻意替换
最容易被忽略的点：NULL 处理逻辑不可绕过，且发生在 WHERE 和 GROUP BY 之后 —— COUNT(列名) 反映的是当前结果集里该列的非空数量，不是原始表分布。一旦在复杂查询里混淆这点，指标偏差不会报错，只会静默出错。
