SQL标准不允许在FROM、JOIN等子句中直接使用变量作为表名，因数据库编译阶段需确定对象结构，而变量值仅运行时可知，必须通过动态SQL实现；SQL Server推荐用sp_executesql配合QUOTENAME()防注入，MySQL需手动校验+反引号拼接，PostgreSQL宜用format('%I')安全转义，且三者均不支持视图/函数内动态表名，仅存储过程可行。
为什么不能直接用变量替换表名
SQL标准不允许在FROM、JOIN等子句中直接使用变量（比如@table_name）作为表名——这会报错Invalid object name '@table_name'。因为SQL Server（或MySQL/PostgreSQL）在编译阶段就需确定对象结构，而变量值只有运行时才可知。
必须走动态SQL这条路，但得清楚：这不是语法糖，而是绕过解析限制的必要手段。
SQL Server里拼接动态SQL最安全的做法
用sp_executesql而非EXEC()，前者支持参数化，能防注入、复用执行计划；后者把整个SQL当字符串拼，风险高且难调试。
- 先用
QUOTENAME()包裹变量表名，自动加[]并转义特殊字符（比如表名含空格或连字符） - 所有用户可控输入（如表名、字段名）都必须过
QUOTENAME()，不能只对表名做、漏掉WHERE里的字段名 - 避免拼接
WHERE条件值，改用sp_executesql的参数占位符（@param）传入
DECLARE @table_name NVARCHAR(128) = 'user_log_202404'; DECLARE @sql NVARCHAR(MAX); DECLARE @params NVARCHAR(MAX) = N'@date_start DATE'; DECLARE @date_start DATE = '2024-04-01'; <p>SET @sql = N'SELECT COUNT(*) FROM ' + QUOTENAME(@table_name) + N' WHERE log_time >= @date_start';</p><p>EXEC sp_executesql @sql, @params, @date_start = @date_start;
MySQL和PostgreSQL怎么处理类似需求
MySQL没有QUOTENAME，得手写校验逻辑：用CONCAT()拼接反引号，并提前检查@table_name是否只含字母、数字、下划线（正则^[a-zA-Z0-9_]+$），否则拒绝执行。
PostgreSQL用format()函数最稳妥：format('SELECT * FROM %I WHERE id = %L', table_name, id_value)，其中%I自动加双引号并转义，%L加单引号并转义字符串值。
- MySQL里别用
PREPARE/EXECUTE传表名参数——它不支持参数化对象名，只能拼字符串 - PostgreSQL的
%I比手动加双引号更可靠，能处理关键词（如order表名） - 三者都不支持在视图或函数里直接用动态表名，存储过程是唯一可行载体
最容易被忽略的权限和作用域问题
动态SQL是在调用者的上下文里执行的，不是存储过程创建者的上下文。如果执行者没被授过目标表的SELECT权限，哪怕存储过程里写了EXECUTE AS OWNER，也照样报The SELECT permission was denied。
- SQL Server建议显式用
EXECUTE AS CALLER或EXECUTE AS 'user_name'控制权限流 - MySQL要确保执行者有对应库+表的
SELECT权限，DEFINER权限模型不覆盖动态语句的对象访问 - 动态SQL里的临时表（
#temp）在sp_executesql结束后就不可见，别指望在后续语句里引用
表名动态化本身不难，难的是把权限、转义、参数边界、执行上下文这四层全兜住——少一层，上线后就可能突然失败。
