GROUP BY + HAVING 无法捕获主键冲突错误，因其属于只读查询机制，不触发存储引擎约束校验；它仅能主动扫描并暴露已存在的重复值，如SELECT id, COUNT() FROM users GROUP BY id HAVING COUNT() > 1。
GROUP BY + HAVING 不能直接检测主键冲突，但能高效发现潜在的主键/唯一键数据不一致问题——比如本该唯一的字段实际出现了重复值。
为什么 GROUP BY + HAVING 无法捕获主键冲突错误
主键冲突（Duplicate entry）是 INSERT/REPLACE/UPDATE 执行时由存储引擎层抛出的运行时错误，属于 DML 阶段；而 GROUP BY 和 HAVING 是 SELECT 查询的逻辑分组与过滤机制，只读不改，不会触发约束校验。你执行 INSERT INTO t VALUES (1,'a') 报错，和你跑 SELECT id FROM t GROUP BY id HAVING COUNT(*) > 1 是两件事。
真正有用的是：用 GROUP BY + HAVING 主动扫描表里「哪些字段本应唯一却已重复」，提前暴露设计缺陷或脏数据。
检查主键字段是否真唯一：用 HAVING COUNT(*) > 1
假设表 users 声明了 id 为主键，但你想确认当前数据是否真的满足唯一性（例如怀疑历史迁移导致重复）：
SELECT id, COUNT(*) AS cnt FROM users GROUP BY id HAVING COUNT(*) > 1;
如果返回任何行，说明主键字段 id 已存在重复值——这违反主键语义，MySQL 实际上不允许这种情况发生（除非禁用严格模式或使用 MyISAM），但 InnoDB 表若曾被手动绕过约束写入、或从损坏备份恢复，就可能出现。
- 必须显式
SELECT id，否则HAVING无法引用分组键 - 别用
COUNT(1)或COUNT(*)以外的聚合，语义不清 - 在大表上执行前加
EXPLAIN，避免全表扫描拖垮线上库
检查唯一索引字段是否被污染：扩展到 UNIQUE 列
业务中常见「用户名唯一」「手机号唯一」等靠 UNIQUE 约束保障，但约束可能被禁用、或应用层未校验就写入。这时查 phone 字段重复：
SELECT phone, COUNT(*) AS cnt FROM users WHERE phone IS NOT NULL GROUP BY phone HAVING COUNT(*) > 1;
WHERE phone IS NOT NULL 很关键——因为 MySQL 中多个 NULL 不被视为重复，UNIQUE 索引允许任意数量 NULL 值，但你通常不希望业务字段大量为空。
- 复合唯一键？写成
GROUP BY col1, col2 - 想看具体哪几行重复？用
GROUP_CONCAT(id)把 ID 拼出来方便定位 - MySQL 8.0+ 可加
ORDER BY cnt DESC LIMIT 5快速聚焦高频重复项
GROUP BY 在主键冲突场景下的真实价值：定位冲突源头
当应用频繁报 Duplicate entry 'xxx' for key 'PRIMARY'，但不确定是哪个字段/哪条数据引发，可结合业务逻辑反向排查。例如订单表 orders 主键是 order_id，但插入失败日志只显示 'ORD-20260826-001'：
先查这个值是否已存在：
SELECT order_id, status, created_at FROM orders WHERE order_id = 'ORD-20260826-001';
再查同类前缀是否泛滥（暴露生成逻辑缺陷）：
SELECT SUBSTRING(order_id, 1, 13) AS prefix, COUNT(*) AS cnt FROM orders WHERE order_id LIKE 'ORD-20260826%' GROUP BY prefix HAVING COUNT(*) > 10;
这类分析不解决冲突本身，但能快速判断是偶发重试、还是 ID 生成器崩了、或是上游并发未加锁。
最易被忽略的一点：HAVING 过滤的是分组后的结果，不是原始行；如果你漏写 GROUP BY 却用了 HAVING，MySQL 5.7 会报错，8.0+ 在严格模式下直接拒绝执行——这不是 bug，是帮你挡住语义错误。
