sql标准禁止在from子句中用子查询结果作为表名，因表名属元数据需解析期确定；动态表名须通过存储过程拼接执行（如postgresql的execute format('%i')或mysql的prepare），且必须校验白名单防注入。
子查询里不能直接写表名，这是SQL标准决定的
SQL语法不允许在FROM子句中用子查询结果动态生成表名。比如SELECT * FROM (SELECT 'users' FROM config) AS t会报错——因为FROM后面必须是真实存在的表或可展开的派生表，不能是字符串值。所谓“动态表名”本质上属于元数据操作，超出了静态SQL的能力边界。
常见错误现象：ERROR: syntax error at or near "(" 或 relation "($subquery)" does not exist，本质都是把字符串当成了标识符。
- PostgreSQL、MySQL、SQL Server 全部不支持该写法，不是配置或版本问题
- 唯一例外是某些数据库的存储过程/函数内支持拼接+执行（如
EXECUTE format(...)），但那已不属于纯SQL范畴 - 应用层拼接SQL字符串虽可行，但必须严格校验表名白名单，否则直接引入SQL注入风险
PostgreSQL用EXECUTE + format()实现运行时表名替换
在PL/pgSQL函数中，可以组合EXECUTE和format()安全地构造并执行含动态表名的语句。关键在于：表名必须作为标识符参数传入format()，用%I占位符自动转义，避免注入。
CREATE OR REPLACE FUNCTION get_table_count(table_name TEXT)
RETURNS INTEGER AS $$
DECLARE
result INTEGER;
BEGIN
EXECUTE format('SELECT COUNT(*) FROM %I', table_name)
INTO result;
RETURN result;
END;
$$ LANGUAGE plpgsql;
使用时：SELECT get_table_count('orders'); —— 注意这里传入的是字符串字面量，%I会把它转为带双引号的合法标识符（如"orders"）。
- 禁止用
%L（字符串字面量）代替%I，否则生成SELECT COUNT(*) FROM 'orders'，语法错误 - 若表名来自用户输入，必须先查白名单表验证存在性，再传入
format() - 无法在普通
SELECT语句中调用该函数实现“一行SQL动态查多表”，函数只能返回标量值
MySQL用PREPARE + CONCAT()拼接动态SQL
MySQL没有内置标识符转义机制，必须手动确保表名只含字母数字和下划线，并通过系统表校验合法性。典型流程：查information_schema.tables确认表存在 → 拼接SQL → PREPARE → EXECUTE。
SET @table_name = 'products';
SET @sql = CONCAT('SELECT COUNT(*) FROM ', @table_name);
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
更安全的做法是加校验：
SELECT COUNT(*) INTO @cnt FROM information_schema.tables WHERE table_schema = DATABASE() AND table_name = @table_name;
- 如果
@cnt = 0，说明表不存在，应中断后续执行 - 禁止直接拼接用户输入的
@table_name，未校验即执行等于开放SQL注入入口 -
PREPARE语句不能跨会话复用，每次都要DEALLOCATE，否则可能耗尽连接资源
为什么不能用视图或CTE绕过这个限制
有人尝试用WITH定义CTE，然后在FROM里引用它来“伪装”动态表名，例如WITH t AS (SELECT 'users' as name) SELECT * FROM t.name —— 这完全无效。CTE输出的是行集，t.name是列值，不是对象名。
视图同理：CREATE VIEW dynamic_ref AS SELECT table_name FROM config，然后SELECT * FROM dynamic_ref拿到的只是字符串，无法被解析为实际表。
- 所有SQL引擎在解析阶段就需确定访问哪些物理表，而CTE/视图内容在执行期才产生
- 试图用
UNION ALL硬编码所有可能表名（如SELECT * FROM users WHERE ?='users' UNION ALL SELECT * FROM logs WHERE ?='logs'）会导致全表扫描，性能灾难且维护困难 - 真正需要动态路由的场景（如分表查询），应该由应用层根据规则选择具体表名，而非强求SQL自己推导
动态表名这件事，核心矛盾在于SQL设计哲学：它处理数据，不处理元数据。一旦涉及“哪个表”，就已经跨到运维或应用逻辑层了。越想在SQL里硬拗，越容易掉进语法陷阱或安全坑里。
