count(*)统计所有行（含null），count(字段)仅统计该字段非null的行；前者语义清晰、性能更优，后者易因忽略null导致计数偏少。
SELECT COUNT(*) 和 COUNT(字段) 的区别在哪
直接用 COUNT(*) 统计行数，它不忽略 NULL，也不关心字段值，只数物理行；而 COUNT(字段名) 只统计该字段非 NULL 的行。比如 COUNT(email) 会跳过 email 为 NULL 的记录。
常见错误是误以为 COUNT(email) 能统计“有邮箱的用户数”，却没意识到如果 email 字段允许 NULL 且实际存在空字符串（''）或空白字符，它们仍会被计入——因为 COUNT() 只跳过真正的 NULL，不跳过空字符串。
- 要严格区分“有值”和“非空字符串”，得配合
WHERE email IS NOT NULL AND email != '' - 聚合前加
DISTINCT（如COUNT(DISTINCT user_id)）能去重计数，但性能开销明显上升，尤其在大数据量时 -
COUNT(*)在大多数数据库（PostgreSQL、MySQL 8.0+、SQL Server）中会被优化为元数据查询，比COUNT(字段)快得多
GROUP BY 配合 COUNT 出现“少了一行”怎么办
当 SELECT COUNT(*) FROM orders GROUP BY status 返回结果比预期少，大概率是因为某类 status 值全为 NULL——GROUP BY 默认把所有 NULL 归为一组，但如果表里压根没有 status IS NULL 的记录，那组就不会出现。
更隐蔽的问题是：某些数据库（如旧版 MySQL）在 sql_mode 不含 ONLY_FULL_GROUP_BY 时，允许 SELECT name, COUNT(*) FROM users GROUP BY status 这种写法，但 name 的值是随机选取的，极易误导分析结果。
- 确保
GROUP BY列与SELECT中非聚合字段完全一致，或仅选聚合字段 - 想强制包含 NULL 分组，可显式写
GROUP BY COALESCE(status, 'unknown')或用UNION ALL单独查 NULL 行 - PostgreSQL 和新版本 MySQL 会直接报错，这是好事，别关掉
ONLY_FULL_GROUP_BY
WHERE 和 HAVING 对 COUNT 的影响顺序
WHERE 在分组前过滤行，HAVING 在分组后过滤组。比如 SELECT status, COUNT(*) FROM orders WHERE amount > 100 GROUP BY status HAVING COUNT(*) > 5：先筛出金额超 100 的订单，再按状态分组，最后只保留订单数超 5 的状态。
典型误用是把本该放 WHERE 的条件塞进 HAVING，比如 HAVING amount > 100——这会先分组再逐组检查，不仅逻辑错（amount 不是聚合字段），还会触发错误或返回意外结果。
-
HAVING只能用聚合函数或GROUP BY中的列 - 想统计“每个用户下单次数 ≥ 3 且最近一次下单在 30 天内”，得拆成子查询或 CTE：
WHERE控制时间，外层HAVING控制次数 - MySQL 8.0+ 支持窗口函数，可用
COUNT(*) OVER (PARTITION BY user_id)替代部分复杂GROUP BY + HAVING场景
COUNT 查询慢，有没有更快的替代方案
对千万级表执行 SELECT COUNT(*) FROM large_table 卡住几秒甚至几分钟，不是因为 SQL 写错了，而是数据库真在挨个数行。InnoDB 尤其明显，因为它不存精确行数，必须扫描索引或聚簇索引。
近似计数（如 PostgreSQL 的 pg_class.reltuples、MySQL 的 SHOW TABLE STATUS）快但不准；缓存计数（应用层维护）准但难保证一致性。真正实用的折中方案有限：
- 加覆盖索引：如果常查
COUNT(*) WHERE deleted = 0，建索引(deleted)或(deleted, id)能显著加速 - 用物化视图（PostgreSQL）或汇总表（MySQL）定期刷新，适合报表类场景
- 避免在 OLTP 事务里实时 COUNT 大表，改用异步任务更新统计值
最常被忽略的是：COUNT 慢往往暴露了设计问题——比如用 COUNT 判断“是否存在”本该用 EXISTS，用 COUNT 分页本该用游标或 LIMIT OFFSET 优化。
