SELF JOIN能查同组重复，是因为将一张表视为两张表，通过ON条件实现组内关联，再用WHERE筛选“同分组且非自身但字段值一致”的异常配对。
SELF JOIN 为什么能查同组重复？
因为 SELF JOIN 本质是把一张表当两张表用，通过 ON 条件建立组内关联，再配合 WHERE 筛出“相同分组但不同行”的配对。关键不是“去重”，而是“找配对”——只要两条记录满足：同一分组（如 group_id 相同）、非自身（t1.id != t2.id）、且字段值异常一致（比如 t1.status = 'ERROR' 且 t2.status = 'ERROR'），就构成一条异常重复线索。
常见错误现象：SELECT * FROM logs t1 JOIN logs t2 ON t1.group_id = t2.group_id 不加 t1.id != t2.id，结果每条记录都和自己配一次，全表翻倍还带大量冗余；或漏写业务过滤条件（如只限定分组，没限定 status 或 error_code），导致把正常重复（如多条成功日志）也拉出来。
怎么写才能精准定位“异常重复”？
核心是三段式过滤：分组对齐 + 自身排除 + 异常标识。以查 orders 表中同一 customer_id 下出现两次及以上 payment_status = 'FAILED' 的记录为例：
SELECT DISTINCT t1.* FROM orders t1 JOIN orders t2 ON t1.customer_id = t2.customer_id AND t1.id != t2.id WHERE t1.payment_status = 'FAILED' AND t2.payment_status = 'FAILED';
实操建议：
-
DISTINCT t1.*防止一个客户有 3 条失败订单时，t1 匹配到 t2 和 t3 产生两行相同 t1 记录 - 必须同时在
WHERE中约束t1和t2的状态，只写t1.payment_status = 'FAILED'不够——否则 t2 可能是 SUCCESS，不构成“双失败”异常 - 若要限制“仅重复 2 次以上”，可改用
GROUP BY t1.customer_id HAVING COUNT(*) > 1配合子查询，但 SELF JOIN 更直观查出原始行
性能差、卡死？这些地方最容易拖慢
SELF JOIN 在大表上极易触发笛卡尔积爆炸，尤其没索引时。以下操作直接影响执行速度：
- 确保
ON字段（如customer_id）有索引；若组合判断（如customer_id + payment_status），建联合索引更优 - 避免在
ON或WHERE中对字段做函数操作，例如ON YEAR(t1.created_at) = YEAR(t2.created_at)会失效索引 - 先用
WHERE尽量缩小参与 JOIN 的数据集，比如加t1.created_at >= '2024-01-01'，比全表 JOIN 再过滤快得多 - 某些数据库（如 MySQL 5.7）对 SELF JOIN 的优化较差，可考虑改用窗口函数：
SELECT * FROM (SELECT *, COUNT(*) OVER (PARTITION BY customer_id, payment_status) AS cnt FROM orders WHERE payment_status = 'FAILED') t WHERE cnt > 1
为什么查出来的记录还是不对？检查这几个点
结果为空或过多，大概率是语义理解偏差或边界没控住：
- 主键/唯一标识是否真能区分“不同行”？如果用
id但部分记录id为 NULL，t1.id != t2.id会跳过所有含 NULL 的行——此时改用(t1.id IS NOT NULL AND t2.id IS NOT NULL AND t1.id != t2.id) - “同组”定义是否包含时间范围？比如“1 小时内同用户重复失败”。这时
ON要加时间差条件：AND ABS(TIMESTAMPDIFF(SECOND, t1.created_at, t2.created_at)) - 业务上是否允许部分字段不同？比如
error_code不同但都算失败。此时WHERE应放宽，但需明确哪些字段必须一致（如customer_id + order_type），哪些可忽略
真正难的不是写 JOIN，而是定义清楚“什么叫异常重复”——它依赖业务规则，而不是语法技巧。一旦定义模糊，SQL 写得再漂亮，结果也只是自洽的错。
