不能。HAVING COUNT(1) > 1 仅识别逻辑重复行，无法暴露联合主键冲突，因其不校验NULL值且不等价于主键约束的非空+唯一性要求。
HAVING COUNT(1) > 1 能不能直接暴露联合主键冲突？
不能。HAVING COUNT(1) > 1 只能查出「逻辑上重复的行」，但它不等于「违反联合主键约束的行」——因为联合主键要求的是 所有组成列非空且组合唯一，而 COUNT(1) 对 NULL 值敏感，且无法区分「本该被主键拒绝但尚未建约束的数据」和「已建约束后 INSERT 失败的报错根源」。
真正要定位联合主键冲突，得先模拟约束校验逻辑
假设你正准备给表 pay 的 No, Year, Month 三列加联合主键，但 ALTER TABLE ... ADD PRIMARY KEY 报了「重复键值」错误。此时应运行等效校验查询：
SELECT No, Year, Month, COUNT(*) AS cnt FROM pay GROUP BY No, Year, Month HAVING COUNT(*) > 1 OR No IS NULL OR Year IS NULL OR Month IS NULL;
这个查询同时覆盖两个硬性条件：
-
GROUP BY后用HAVING COUNT(*) > 1找出组合重复项 - 显式检查各列是否为
NULL（因为主键列不允许NULL，但GROUP BY会把NULL当作相同值聚合，单靠COUNT会漏掉）
为什么别用 COUNT(1) 替代 COUNT(*)？
在绝大多数场景下，COUNT(1) 和 COUNT(*) 行为一致，但有两点隐患：
- 某些旧版 MySQL（如 5.6 之前）对
COUNT(1)的优化路径不如COUNT(*)稳定，执行计划可能多走一次列扫描 - 语义上，
COUNT(*)明确表达「统计行数」，而COUNT(1)容易让人误以为在计算常量表达式，干扰协作理解 - 当字段存在隐式转换（比如
Year是CHAR类型存数字），COUNT(1)不暴露类型问题，但真实建主键时会因类型不匹配直接失败
查到重复后，怎么安全清理再建主键？
不要直接 DELETE 所有重复行——业务可能需要保留最新或最完整的一条。推荐分步操作：
- 先备份：
CREATE TABLE pay_backup AS SELECT * FROM pay; - 用
ROW_NUMBER()标记重复组内序号：SELECT *, ROW_NUMBER() OVER (PARTITION BY No, Year, Month ORDER BY id DESC) AS rn FROM pay
- 删掉每组中
rn > 1的行（保留id最大的那条）：DELETE p1 FROM pay p1 INNER JOIN pay p2 ON p1.No = p2.No AND p1.Year = p2.Year AND p1.Month = p2.Month AND p1.id
- 确认无重复且无
NULL后，再执行：ALTER TABLE pay ADD PRIMARY KEY (No, Year, Month);
最关键的细节是：建主键前必须确保没有 NULL，且重复判断字段和 GROUP BY 字段完全一致——少一个字段，就可能让冲突数据逃过检测。
