SQL Server中表名和字段名必须拼接进字符串并用QUOTENAME()转义，因编译期需确定对象结构，变量无法直接替代；值参数须用sp_executesql占位符传入，严禁拼接。
SQL Server里表名和字段名必须拼进字符串，不能参数化
SQL Server不允许在FROM、JOIN、INSERT INTO等位置直接用变量代替表名或字段名——这不是写法问题，而是解析机制决定的：编译阶段就要确认对象结构，而变量值只在运行时才存在。所以SELECT * FROM @table_name会报错Must declare the scalar variable "@table_name"，本质是语法不被允许。
唯一可行路径是把表名、字段名这些「标识符」拼进@sql字符串里，再用sp_executesql或EXEC执行。但拼接本身有风险，必须校验+转义：
-
QUOTENAME(@table_name)是必须步骤，它自动加[]并转义特殊字符（比如user; DROP TABLE x→[user; DROP TABLE x]） - 字段名列表（如
@field_list）同样要过QUOTENAME，逐个处理再STRING_AGG拼接，不能直接CONCAT('SELECT ', @field_list, ' FROM ...') - WHERE条件里的值（如
@id）必须走sp_executesql的参数占位符，绝不能拼进字符串
MySQL中拼表名得手动校验+反引号包裹
MySQL没有QUOTENAME，也不能用PREPARE传表名参数——PREPARE stmt FROM 'SELECT * FROM ?'会直接报错ERROR 1064，因为?只支持字面值，不支持对象名。
你只能手写白名单校验，再用CONCAT()拼反引号：
- 先用正则检查：
@table_name REGEXP '^[a-zA-Z0-9_]+$'，拒绝含空格、分号、连字符的输入 - 拼接时强制加反引号：
CONCAT('SELECT * FROM `', @table_name, '` WHERE id = ?') - 字段名同理，但要注意：如果字段名来自用户输入（比如前端选列），必须同样校验，不能只信前端传来的字符串
PostgreSQL用format('%I')比手拼双引号更可靠
PostgreSQL的format()函数专为动态SQL设计：%I自动加双引号并转义关键词（比如表名叫order，format('SELECT * FROM %I', 'order')会生成SELECT * FROM "order"），而手拼'"order"'容易漏掉转义或引号配对错误。
关键点：
-
%I只用于表名、字段名等标识符；%L用于字符串值（如WHERE name = 'Alice'）；混用会出错（%L给表名会变成'my_table'，语法非法） - 字段列表不能直接
format('SELECT %I FROM ...', @fields)——%I只处理单个标识符，多个字段得拆开循环format再array_to_string拼接 - 动态JOIN时，两边字段类型必须显式对齐，否则隐式转换会让索引失效，比如
ON t1.id = t2.id_str::int比ON t1.id = CAST(t2.id_str AS INTEGER)更清晰
所有数据库都不支持在视图或函数里动态表名
无论SQL Server、MySQL还是PostgreSQL，视图定义和标量/表值函数都要求结构静态可解析，动态表名会直接报错。存储过程是唯一能承载这类逻辑的载体。
容易被忽略的坑：
- 动态SQL在调用者上下文执行，不是存储过程定义者的权限——如果调用者没目标表SELECT权限，
sp_executesql照样失败 - SQL Server中
sys.tables查表存在性时，必须JOINsys.schemas限定schema，否则可能匹配到其他库的同名表 - MySQL的
@sql变量必须是用户变量（SET @sql = ...），存储过程里的局部变量DECLARE sql_text TEXT无法被PREPARE识别
