SQL Server中能否通过带JOIN的单SELECT返回多个结果集？

嘿，我懂你想要实现的效果——把左连接后tableA和tableB的对应数据分别存下来，再返回各自去重的结果对吧？你说的语法问题确实是SQL Server的规则限制：没法直接用select ... into @变量这种方式把整张表的结果存到变量里。不过有几个简单实用的方案能达成你的目标，我给你详细说说：

方案1：使用本地临时表（最灵活的选择） #

临时表不需要提前定义结构，select ... into会自动根据查询结果生成表结构，非常适合你的场景：

BEGIN
    -- 存储左连接后tableA的所有匹配数据
    SELECT A.* INTO #TempA
    FROM tableA AS A
    LEFT JOIN tableB AS B ON A.id = B.id_A;

    -- 存储左连接后tableB的有效匹配数据（过滤掉左连接产生的NULL行）
    SELECT B.* INTO #TempB
    FROM tableA AS A
    LEFT JOIN tableB AS B ON A.id = B.id_A
    WHERE B.id_A IS NOT NULL;

    -- 返回去重后的tableA数据
    SELECT DISTINCT * FROM #TempA;
    -- 返回去重后的tableB数据
    SELECT DISTINCT * FROM #TempB;

    -- 手动清理临时表（可选，会话结束后会自动删除）
    DROP TABLE IF EXISTS #TempA;
    DROP TABLE IF EXISTS #TempB;
END

本地临时表（以#开头）只在当前会话可见，不会干扰其他用户的操作，而且不需要提前知道表结构，用起来很省心。

方案2：使用表变量（适合小数据量场景） #

如果一定要用变量存储，那得先定义和原表结构一致的表变量，再插入数据：

BEGIN
    -- 定义与tableA结构完全匹配的表变量
    DECLARE @TempA TABLE (
        id INT, -- 替换成tableA实际的列名和数据类型
        column1 VARCHAR(50),
        column2 DATETIME,
        -- 补充tableA的其他列...
    );

    -- 定义与tableB结构完全匹配的表变量
    DECLARE @TempB TABLE (
        id_A INT, -- 替换成tableB实际的列名和数据类型
        columnX INT,
        columnY VARCHAR(100),
        -- 补充tableB的其他列...
    );

    -- 插入tableA的匹配数据到表变量
    INSERT INTO @TempA
    SELECT A.*
    FROM tableA AS A
    LEFT JOIN tableB AS B ON A.id = B.id_A;

    -- 插入tableB的有效匹配数据到表变量
    INSERT INTO @TempB
    SELECT B.*
    FROM tableA AS A
    LEFT JOIN tableB AS B ON A.id = B.id_A
    WHERE B.id_A IS NOT NULL;

    -- 返回去重结果
    SELECT DISTINCT * FROM @TempA;
    SELECT DISTINCT * FROM @TempB;
END

表变量的生命周期是当前批处理，结束后自动销毁，不需要手动清理，但缺点是必须提前明确列结构，表结构变更时要同步修改变量定义。

方案3：直接查询（无需存储中间结果） #

如果不需要复用中间数据，其实可以直接写两个查询，效率反而更高：

BEGIN
    -- 直接返回tableA中与tableB关联过的去重数据
    SELECT DISTINCT A.*
    FROM tableA AS A
    LEFT JOIN tableB AS B ON A.id = B.id_A;

    -- 直接返回tableB中与tableA匹配的去重数据（用内连接过滤无效行）
    SELECT DISTINCT B.*
    FROM tableB AS B
    INNER JOIN tableA AS A ON B.id_A = A.id;
END

这种方式省去了存储中间数据的步骤，适合只需要一次性返回结果的场景。

另外提一句：你提到的游标确实能实现，但游标是逐行处理数据，效率极低，完全不适合这种批量提取数据的需求，所以上面的方案会更优。

内容的提问来源于stack exchange，提问作者Eduardo Rauchbach