self join导致重复结果是因为它本质是笛卡尔积匹配，会生成所有满足on条件的行对组合，包括(a,b)和(b,a)镜像对及(a,a)自匹配，而非业务所需的无序唯一组合。
为什么直接 JOIN 同一张表会导致重复结果？
Self JOIN 本身不保证去重，它只是把表按条件配对——比如查“谁和谁住在同一城市”，users u1 JOIN users u2 ON u1.city = u2.city 会把 (A,B) 和 (B,A) 都算一遍，还包含 (A,A)。这不是业务要的“无重复组合”，而是笛卡尔积的副产品。
常见错误现象：SELECT u1.name, u2.name 返回两倍预期行数，甚至出现自己匹配自己的记录。
- 用
u1.id 替代 <code>=或!=：确保每对只出现一次，且排除自匹配 - 若业务允许 (A,B) 和 (B,A) 视为相同（如“好友关系”），必须加单向比较，否则逻辑错乱
- 注意 NULL 城市字段：若
city可为空，u1.city = u2.city会跳过所有含 NULL 的行——需显式处理IS NOT DISTINCT FROM（PostgreSQL）或用COALESCE（MySQL/SQL Server）
ROW_NUMBER() + 自连接：适合需要“每个用户只参与一次配对”的场景
当你要避免同一个用户出现在多行结果中（比如给用户两两分组做任务分配），靠 不够，得用窗口函数控制参与资格。
示例：给同城市用户两两配对，每人最多出现一次
WITH ranked AS (
SELECT id, name, city,
ROW_NUMBER() OVER (PARTITION BY city ORDER BY id) AS rn
FROM users
)
SELECT r1.name, r2.name
FROM ranked r1
JOIN ranked r2 ON r1.city = r2.city AND r1.rn
-
ROW_NUMBER()按城市分组编号，确保顺序可预测 -
r1.rn % 2 = 1锁定奇数位作为“发起方”，r2.rn = r1.rn + 1强制紧邻配对 - 性能敏感时慎用：窗口函数 + 自连接可能触发全表扫描，城市分布不均时小城市会缺配对
用 DISTINCT ON（PostgreSQL）或 GROUP BY 简化逻辑
如果目标不是列出所有组合，而是“每个用户找一个同城市伙伴”，就别硬套 JOIN——用聚合或去重更直接。
PostgreSQL 示例（取每个用户字典序最小的同城伙伴）：
SELECT DISTINCT ON (u1.id)
u1.name AS user_name,
u2.name AS partner_name
FROM users u1
JOIN users u2 ON u1.city = u2.city AND u1.id != u2.id
ORDER BY u1.id, u2.name;
-
DISTINCT ON (u1.id)保证每个u1.id只出一行，ORDER BY控制选哪一行 - MySQL/SQL Server 没
DISTINCT ON，得用ROW_NUMBER() OVER (PARTITION BY u1.id ORDER BY u2.name)+ 外层过滤rn = 1 - 别在
JOIN条件里写u1.id != u2.id后又忘了加索引——(city, id)复合索引能显著提速
真正容易被忽略的点：NULL、大小写、空格和字符集
自连接去重失效，80% 不是因为逻辑写错，而是数据本身有陷阱。
-
city字段含前后空格？先TRIM(u1.city) = TRIM(u2.city)，否则 “Beijing ” ≠ “Beijing” - 大小写敏感？MySQL 默认不敏感，PostgreSQL 敏感——统一用
LOWER(TRIM(u1.city))更稳妥 - 中文城市名混入全角空格或异体字？简单
TRIM不够，需预处理或用正则标准化 - 字符集不一致（如 utf8mb4 vs latin1）会导致隐式转换失败，
JOIN直接不命中——查SHOW CREATE TABLE users确认列字符集
数据质量比 JOIN 写法重要得多。没清理干净前，再优雅的 SQL 也只在返回错误的“无重复”结果。
