如何直接执行基于primary_table条件动态生成的SQL脚本？

先排查动态SQL本身的正确性 #

不管用EXEC还是sp_executesql，先确保拼接出来的SQL本身合法：

• 执行脚本里的PRINT(@tab1)，把输出的SQL复制到新查询窗口直接运行。
• 如果这个静态SQL报错，先解决核心问题：比如检查UNION ALL是否多写了最后一个、表名是否正确、列结构是否真的完全一致（哪怕列顺序或类型有差异都会报错）、是否存在不存在的表。

修正动态SQL拼接逻辑 #

很多报错源于拼接的SQL有语法瑕疵，推荐用更可靠的拼接方式代替循环赋值：

DECLARE @tab1 NVARCHAR(MAX);

-- 用FOR XML PATH拼接，自动处理空值和多余的UNION ALL
SELECT @tab1 = STUFF((
    SELECT ' UNION ALL SELECT * FROM [Table_' + CAST(id AS VARCHAR(10)) + ']'
    FROM primary_table
    WHERE consider = 'Yes'
    FOR XML PATH(''), TYPE
).value('.', 'NVARCHAR(MAX)'), 1, 11, '');

-- 仅当有符合条件的表时执行
IF @tab1 IS NOT NULL
BEGIN
    EXEC sp_executesql @tab1;
END
ELSE
BEGIN
    PRINT '没有符合条件的表需要合并';
END

关键修正点： #

• 用[Table_X]包裹表名：避免表名是关键字或含特殊字符导致解析错误。
• STUFF函数去掉开头多余的UNION ALL：手动循环拼接容易留下最后一个多余的UNION ALL，这是常见语法错误。
• 使用sp_executesql代替EXEC：它对长SQL支持更好，且支持参数化（后续加条件更安全），同时要求参数为NVARCHAR类型，避免编码或截断问题。

其他排查方向 #

1. 变量类型问题：确保@tab1是NVARCHAR(MAX)类型，而非VARCHAR(MAX)，sp_executesql要求输入的SQL字符串为Unicode类型，用VARCHAR可能导致截断或编码错误。
2. 权限问题：执行脚本的账号需要有primary_table的查询权限，以及所有待合并的Table_1至Table_6的查询权限。动态SQL会继承当前执行账号的权限，权限不足会直接报错。
3. id字段合法性：检查primary_table中consider='Yes'对应的id是否都是1-6的数字，避免拼接出不存在的表名（比如Table_7）导致报错。

内容的提问来源于stack exchange，提问作者manu p