在编写SQL多表关联查询时，可能会遇到一个比较隐蔽的问题：单独查询每张表的数据量都正常，一旦使用JOIN连接起来，结果行数却意外翻倍甚至更多。调试半天才发现，不是数据库统计信息出错，也不是SQL语法写错，而是连接条件本身没有保证唯一性。当连接键在关联表中出现重复值时，JOIN操作会把左表的每一行与右表所有匹配行进行组合，导致结果集迅速膨胀。这篇文章会从连接唯一性检查入手，分析行数放大的根本原因，并给出几种实用的去重处理方案。

一、连接条件唯一性缺失是如何放大行数的

先理解JOIN的匹配机制。以最常用的INNER JOIN为例，数据库会对左表和右表按照ON条件进行匹配，只要连接键相等，就会生成一条结果记录。如果左表某一行在右表中有三条匹配行，那么这一行就会在结果中出现三次。同样，如果右表某一行在左表中有两条匹配行，也会出现两次。当两边都出现重复时，行数会按照笛卡尔积的方式放大：左表匹配行数乘以右表匹配行数。

举一个典型的例子。假设有订单表orders和支付表payments，订单表记录每个订单基本信息，支付表记录每笔支付流水。正常情况下，一个订单可能对应多笔支付，但如果支付表的order_id没有唯一约束，就可能出现同一笔支付被重复记录，或者连接时把其他维度也带进来导致重复。下面创建两张模拟表并插入包含重复连接键的数据。

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_name VARCHAR(50),
    total_amount DECIMAL(10,2)
);
CREATE TABLE payments (
    payment_id INT PRIMARY KEY,
    order_id INT,
    pay_amount DECIMAL(10,2),
    pay_time DATETIME
);
INSERT INTO orders VALUES
(1, '张三', 199.00),
(2, '李四', 299.00);
INSERT INTO payments VALUES
(101, 1, 99.00, '2025-01-01 10:00:00'),
(102, 1, 100.00, '2025-01-01 11:00:00'),
(103, 1, 100.00, '2025-01-01 11:05:00');

上面的payments表中order_id为1出现了三次，其中第三次是重复支付。如果执行下面的关联查询：

SELECT o.order_id, o.customer_name, p.payment_id, p.pay_amount
FROM orders o
INNER JOIN payments p ON o.order_id = p.order_id;

结果会返回3行，对于订单1来说，payments表中有3条匹配，如果业务预期一个订单只有两笔支付，那么结果中就多了一行。如果再把另一个存在重复的维度表JOIN进来，行数会进一步放大。例如连接一张有重复订单号的发票表，最终结果可能变成订单数乘以支付重复数乘以发票重复数，出现几十行也不奇怪。因此，连接条件唯一性是保证多表JOIN结果准确的前提，发现问题时要先定位是哪张表的连接键出现了重复。

二、检查连接条件唯一性的几种方法

定位重复来源时，最直接的办法是对关联表中的连接键进行分组统计。通过GROUP BY加HAVING可以找出哪些键出现了多次，从而判断是否因为重复导致行数放大。以payments表为例，执行下面的语句：

SELECT order_id, COUNT(*) AS cnt
FROM payments
GROUP BY order_id
HAVING COUNT(*) > 1;

如果查询返回了order_id为1的记录，说明这个连接键在payments表中并不唯一。除了手动统计，还可以查看表结构中的主键和唯一索引。主键本身保证唯一，外键通常不保证唯一，这也是很多关联查询出错的原因：开发者误以为外键列天然唯一，实际上外键只是引用另一个表的主键，在当前表中可以重复出现。

如果表的数据量很大，可以借助执行计划观察连接类型和预计行数。例如在MySQL中使用EXPLAIN，关注rows字段和join type。当发现驱动表被选为行数多的表，或者被驱动表扫描行数远大于预期，就要怀疑连接键是否唯一。有些数据库支持CHECK约束和唯一索引，可以通过SHOW INDEX FROM table_name查看索引信息。另一个快速定位方法是把连接条件改成LEFT JOIN并统计右表连接键出现次数，或者使用窗口函数COUNT(*) OVER(PARTITION BY order_id)来标记每个order_id在表中的出现次数。

检查唯一性的目的并不仅仅是为了去重，更重要的是判断数据模型是否存在设计缺陷。如果业务上连接键本来就应该唯一，那么重复数据就是脏数据，应该在写入端纠正，而不是每次都靠查询去重来掩盖问题。只有明确了唯一性要求，后续的去重方案才有依据。

三、去重处理：DISTINCT、GROUP BY与预聚合

当连接键存在重复但暂时无法修改数据时，查询端去重是最快速的解决办法。最常见的是在SELECT后面加DISTINCT，对整个结果集去重。比如上一个例子中，如果希望每个订单只显示一条支付总额，可以先把支付表按订单聚合再关联：

SELECT o.order_id, o.customer_name, p.total_paid
FROM orders o
INNER JOIN (
    SELECT order_id, SUM(pay_amount) AS total_paid
    FROM payments
    GROUP BY order_id
) p ON o.order_id = p.order_id;

这种方式叫做预聚合，它从源头消除了重复行，比直接对最终结果DISTINCT更高效，尤其在数据量大时能显著减少关联阶段的数据量。使用DISTINCT虽然简单，但会把所有列组合去重，如果只想去掉部分重复列，可能达不到预期，而且DISTINCT会对结果集排序或哈希去重，开销较大。

GROUP BY也可以用于去重，特别是配合聚合函数取MIN、MAX或任意值。例如当订单支付表中有多条记录但只关心最早支付时间时：

SELECT o.order_id, o.customer_name, MIN(p.pay_time) AS first_pay_time
FROM orders o
LEFT JOIN payments p ON o.order_id = p.order_id
GROUP BY o.order_id, o.customer_name;

这里用GROUP BY将每个订单的多行压缩为一行，并通过MIN选择最早时间。需要注意，GROUP BY去重要求SELECT中的非聚合列必须出现在GROUP BY中，否则会报错或产生不确定结果。另外，如果业务需要保留重复行中的某一条完整记录，比如取最新一笔支付，单纯GROUP BY就不够用了，需要借助窗口函数或自连接。

四、用窗口函数和半连接替代JOIN去重

对于更复杂的去重需求，窗口函数提供了灵活的能力。ROW_NUMBER()可以按连接键分组并编号，然后外层过滤编号为1的行，从而保留每组中的一条记录。例如要获取每个订单最新的一笔支付记录，可以这样写：

SELECT order_id, payment_id, pay_amount, pay_time
FROM (
    SELECT order_id, payment_id, pay_amount, pay_time,
           ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY pay_time DESC) AS rn
    FROM payments
) t
WHERE rn = 1;

这个查询先在子查询中为每个order_id按照支付时间倒序编号，最新的一笔编号为1，外层只保留编号为1的行，从而实现按订单去重。窗口函数不会减少原始数据行数，但可以精确控制保留规则，比DISTINCT更灵活。

如果目标只是判断订单是否存在支付记录，而不需要返回支付表的字段，可以用半连接替代JOIN。EXISTS和IN子查询天然只关心存在性，不会像JOIN那样放大行数。下面的查询返回有过至少一笔支付的订单：

SELECT o.order_id, o.customer_name
FROM orders o
WHERE EXISTS (
    SELECT 1
    FROM payments p
    WHERE p.order_id = o.order_id
);

这种写法不会产生重复行，因为对于每个订单，只要子查询找到至少一条支付记录就返回该订单一次。相比JOIN后DISTINCT，半连接通常执行效率更高，优化器可以将其转换为semi join或anti join。在实际优化SQL时，如果你发现自己正在用JOIN加DISTINCT来消除因连接键重复产生的冗余行，不妨先停下来思考：是否真的需要用到右表的字段？如果不需要，改用EXISTS或IN往往能从根源上避免行数膨胀。