EXECUTE不能直接用于JOIN场景，因其是运行时指令而非表对象，必须将含动态表名的完整SELECT语句拼接后执行，并用QUOTENAME等防注入。
EXECUTE 不能直接用于 JOIN 场景
SQL 标准里 EXECUTE（或 EXEC）是执行动态语句的命令，但它本身不参与查询计划构建，无法嵌入在 SELECT ... FROM ... JOIN 中作为表名或连接逻辑的一部分。你写不出类似 SELECT * FROM t1 JOIN EXECUTE('SELECT * FROM ' + @table_name) 这样的语法——它会直接报错，比如 SQL Server 报 Incorrect syntax near 'EXECUTE'，PostgreSQL 报 syntax error at or near "EXECUTE"。
根本原因是：JOIN 的右侧必须是可解析的表对象（物理表、视图、CTE、子查询），而 EXECUTE 是运行时指令，不是表达式，不能返回“表引用”。
用字符串拼接 + EXECUTE 构建完整 SELECT
可行路径只有一条：把整个 SELECT 语句（含动态表名、字段、ON 条件）拼成字符串，再用 EXECUTE（SQL Server 用 EXEC 或 sp_executesql，PostgreSQL 用 EXECUTE）执行。
关键点：
- 表名、字段名、ON 条件中的列名都必须来自可信来源（如配置表字段），严禁直接拼接用户输入，否则触发 SQL 注入
- SQL Server 推荐用
sp_executesql而非EXEC，便于参数化 WHERE 条件（但表名仍不能参数化） - PostgreSQL 中
EXECUTE必须配合USING传值，且动态表名只能拼接，不能用USING代入
示例（SQL Server）：
DECLARE @sql NVARCHAR(MAX), @join_table SYSNAME = 'orders_2024';
SET @sql = N'SELECT u.id, u.name, o.amount
FROM users u
LEFT JOIN ' + QUOTENAME(@join_table) + N' o ON u.id = o.user_id';
EXEC sp_executesql @sql;注意 QUOTENAME() 防注入，不可省略；sp_executesql 比 EXEC(@sql) 更安全、可复用执行计划。
配置表驱动的多表关联如何落地
如果业务要求“根据配置决定 JOIN 哪张明细表”，比如按月份切分订单表 orders_202401、orders_202402，配置存在 config_table 中：
- 先查配置：用普通
SELECT @target_table = table_name FROM config_table WHERE key = ''current_order_table'' - 再拼 SQL：确保
@target_table经过QUOTENAME（SQL Server）或format('"%I"', table_name)（PostgreSQL）转义 - 避免硬编码字段：若不同订单表结构不一致，需同步查配置表获取字段映射，例如
SELECT join_column, select_columns FROM config_table WHERE table_name = @target_table - 性能隐患：每次执行都生成新执行计划，无法重用；高频调用时考虑缓存拼好的 SQL 字符串（带参数占位符）
替代方案：用视图或通用表 + 分区裁剪
真正需要“动态 JOIN 表”的场景，往往说明设计可优化。更健壮的做法是：
- 合并所有分表为一个逻辑表：SQL Server 用分区表，PostgreSQL 用继承表或
UNION ALL视图，让优化器自动裁剪 - 用视图封装路由逻辑：
CREATE VIEW current_orders AS SELECT * FROM orders_202406，应用层只查current_orders，配置变更只需改视图定义 - 应用层控制 JOIN：把表名、条件判断逻辑移到应用代码（Python/Java），生成完整 SQL 后发送，数据库只负责执行——分离关注点，也更容易测试和审计
动态拼接 SQL 看似灵活，但调试困难、权限难控、执行计划碎片化。除非配置变更极低频且 DBA 明确允许，否则优先走视图或应用层组装。
