HAVING COUNT() = 1 是筛选单条记录分组的正确写法，必须配合 GROUP BY；WHERE 中使用 COUNT() 会报错，因聚合函数只能在分组后计算。
用 HAVING COUNT = 1 筛选单条记录的分组
直接结论：HAVING COUNT(*) = 1 是最常用且可靠的写法，但必须配合 GROUP BY，不能单独用在 WHERE 里——否则会报错或逻辑错误。
常见错误现象：写成 WHERE COUNT(*) = 1，MySQL 直接报错 Invalid use of group function；PostgreSQL 提示 column must appear in the GROUP BY clause。
-
GROUP BY字段必须覆盖所有非聚合列（比如你SELECT id, name，那GROUP BY至少得包含id, name，否则结果不可靠） - 如果只关心“哪些分组唯一”，
SELECT列建议只写GROUP BY字段，避免歧义 - 某些旧版 MySQL（5.7 严格模式关闭时）允许
SELECT *+GROUP BY a，但返回哪一行是随机的，千万别依赖
为什么不能用 WHERE 而必须用 HAVING
WHERE 在分组前过滤行，HAVING 在分组后过滤组——COUNT(*) 是聚合函数，只能作用于分组后的结果集。
举个例子：查每个 user_id 下只提交过一次订单的用户。
SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) = 1;
如果误写成：
SELECT user_id FROM orders WHERE COUNT(*) = 1 -- ❌ 语法错误 GROUP BY user_id;
就会失败。因为 WHERE 还没看到“分组”，根本不知道“这个 user_id 对应几条”。
COUNT(1)、COUNT(*)、COUNT(id) 有区别吗
绝大多数情况下没区别，但细节影响语义和兼容性：
-
COUNT(*)统计行数，不关心字段是否为NULL，标准、安全、推荐 -
COUNT(1)和COUNT(*)在主流数据库（MySQL、PostgreSQL、SQL Server）里执行计划几乎一样，但语义模糊——1 不是列，容易让协作者困惑 -
COUNT(id)只统计id IS NOT NULL的行，如果id允许为空，结果可能少于实际分组行数 - Oracle 早期版本对
COUNT(*)有额外优化，虽现在基本无差别，但统一用COUNT(*)更稳妥
性能与索引注意事项
单纯 HAVING COUNT(*) = 1 无法走索引加速分组本身，但可以靠前置条件缩小数据集：
- 先用
WHERE过滤掉大量无关数据（比如加时间范围、状态条件），再分组，比全表分组快得多 - 如果经常按某字段分组查唯一性，给该字段建索引能加快
GROUP BY排序阶段（尤其 MySQL 的Using filesort场景） - PostgreSQL 中，
GROUP BY字段若带索引且查询只涉及索引列，可能触发Index Only Scan，但HAVING条件仍需内存计算，别指望索引直接跳过分组
真正容易被忽略的是：当分组键基数极高（比如 UUID 字段），GROUP BY 本身内存开销大，即使最终只有几条满足 COUNT = 1，也要先把全部分组建出来——这时候得考虑是否真需要 SQL 层解决，还是改用应用层聚合更合适。
