SQL嵌套查询中无法直接用变量拼接表名，必须使用动态SQL（如MySQL的PREPARE/EXECUTE或PostgreSQL的EXECUTE+format）实现；应用层拼SQL易引发注入、权限和缓存问题，应优先采用白名单校验或存储过程。
SQL嵌套查询里不能直接用变量拼表名
这是最常卡住人的地方：你写 SELECT * FROM (SELECT * FROM @table_name) t，会直接报错——SQL标准不支持在FROM子句中用变量代替表名。哪怕外层是嵌套查询，@table_name 依然只是字符串变量，不是可解析的标识符。所有主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）都这样，不是语法写错了，是根本没这个能力。
真正能“动态换表”的，只有动态SQL——也就是把整个语句拼成字符串，再交给执行引擎重编译一次。
MySQL中用PREPARE + EXECUTE实现嵌套动态表名
MySQL最常用的方式是组合 CONCAT、PREPARE 和 EXECUTE。注意两点：一是表名必须显式拼进字符串，二是嵌套结构要靠括号和别名维持语义正确性。
比如你想查「某张日志表中最近10条错误记录」，表名由参数决定：
SET @tbl = 'log_202405';
SET @sql = CONCAT('SELECT * FROM (SELECT id, msg, created_at FROM ', @tbl, ' WHERE level = ''ERROR'' ORDER BY created_at DESC LIMIT 10) AS t');
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;常见坑：
- @tbl 如果含非法字符（如破折号、空格），必须用反引号包裹：CONCAT('SELECT * FROM `', @tbl, '` ...')
- PREPARE 作用域是会话级，不能跨连接复用；DEALLOCATE 不做会导致内存泄漏
- 子查询必须带别名（如 AS t），否则外层 FROM (...) t 会报语法错误
PostgreSQL里用EXECUTE配合format()拼接嵌套查询
PostgreSQL没有 PREPARE 的会话级变量机制，必须在函数或DO块里用 EXECUTE + format()。关键点在于：嵌套查询的括号层级、别名、以及表名必须用 %I 格式化（自动加双引号防SQL注入），不能用 %L（那是给字面量的）。
示例（匿名块）：
DO $$
DECLARE
tbl_name TEXT := 'events_june';
dyn_sql TEXT;
BEGIN
dyn_sql := format('SELECT count(*) FROM (SELECT * FROM %I WHERE status = ''active'') AS sub');
EXECUTE dyn_sql INTO some_var;
END $$;注意：
- %I 是必须的，写成 %L 会让表名变成字符串字面量，执行时报 relation "events_june" does not exist（因为实际找的是叫 events_june 的字符串值，不是表）
- 如果嵌套里还要传参数（比如WHERE条件值），得用 USING 子句，不能硬拼到字符串里
- EXECUTE 返回结果必须用 INTO 捕获，没法直接 SELECT 出来
为什么不该在应用层拼SQL？
有人图省事，在Python/Java里用f-string拼出完整SQL再发给数据库。这看起来快，但问题集中爆发：SQL注入风险陡增、表名大小写敏感导致运行时失败、权限校验失效（DBA通常只给固定表的SELECT权限）、无法利用查询缓存（每次都是新语句）。
更稳妥的做法：
- 表名白名单校验：只允许 ['user_log', 'order_history', 'payment_2024q2'] 这类预定义值
- 把动态逻辑下沉到存储过程里，由DBA审核并赋予最小权限
- 真需要灵活性时，优先考虑分区表或视图抽象，而不是每条语句都动态生成
动态SQL本身没问题，但嵌套+动态表名=两层解析时机错位，最容易漏掉权限、注入、语法闭合这些细节。
