count()统计行是否存在，count(列名)统计该列非NULL值数量；前者不读列值、性能优，后者需取值判空、可能全表扫描；NULL值导致计数偏差，须用COUNT()-COUNT(列名)验证。
count(*) 统计的是“行是否存在”，count(列名) 统计的是“该列是否非 NULL”
这是根本差异，不是 bug，是 SQL 标准强制行为。count(*) 只关心某行是否被 WHERE 条件选中（或全表时是否物理存在），完全不读取任何列值；而 count(列名) 必须读出该列实际内容，并跳过所有为 NULL 的行。
哪怕该列是主键、有索引、甚至定义为 NOT NULL，只要执行时某行该列值为 NULL（比如应用层显式插入 NULL，或触发器写入），它就不会被计入 count(列名)。
- 常见静默偏差场景：
INSERT INTO users (name) VALUES ('Alice')——email列允许NULL且没给值，这行的email就是NULL -
LEFT JOIN后对右表字段计数：COUNT(orders.id)实际统计的是“成功关联的订单数”，不是左表原始行数 - 字段原为
NOT NULL，后来ALTER TABLE ... MODIFY email VARCHAR(255) NULL，旧逻辑未改，结果开始变少
验证某列有多少 NULL 值，别靠猜，直接算差值
最可靠的方式就是并列查两个值：
SELECT COUNT(*) AS total, COUNT(email) AS non_null, COUNT(*) - COUNT(email) AS null_count FROM users;
如果 null_count > 0，说明该列确实存在 NULL，此时用 COUNT(email) 统计“用户总数”就必然漏掉这些行。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
''（空字符串）、0、false都算非NULL，会被COUNT(列名)计入 - 字符串
'NULL'是普通文本，照样计入 - 只有真正的 SQL
NULL被跳过
count(*) 通常比 count(列名) 快，尤其在 InnoDB 大表上
性能差距不是配置问题，而是引擎行为决定的：
-
COUNT(*)：优化器可选最小二级索引（如只存主键的索引），遍历叶子节点即可，不回表、不读列值 -
COUNT(列名)且该列允许NULL：必须访问聚簇索引（即整行数据），只为取一个字段+判空——相当于强制全表扫描 -
COUNT(列名)即使该列有索引，若类型大（如TEXT）或索引不覆盖，仍可能回表 - 实测：100 万行表，
COUNT(*)耗时 0.03 秒，COUNT(email)（email允NULL）达 0.28 秒
count(1) 和 count(*) 在 MySQL 8.0+ 几乎没区别，但语义更推荐后者
COUNT(1) 会被优化器等价重写为 COUNT(*)，执行计划、扫描范围、耗时基本一致。但仍有细微差别：
-
COUNT(*)是 SQL92 标准语法，MySQL 对其做了深度适配，语义明确、协作不易误解 -
COUNT(1)在极少数嵌套视图或复杂子查询中，可能触发非预期执行计划 - server 层对
COUNT(1)仍需“硬塞一个常量再判空”，多一层抽象；COUNT(*)直接告诉引擎“我要行数”，路径更短
真正影响性能的是：是否有 WHERE 条件、索引覆盖程度、列是否允许 NULL——而不是括号里写 * 还是 1。最容易被忽略的一点是：NULL 判断发生在 WHERE 和 GROUP BY 之后，COUNT(列名) 反映的是当前结果集里的非空数量，不是原始表分布。一旦在带条件的复杂查询里混淆这点，指标偏差不会报错，只会静默出错。
