SQL Server用sp_executesql动态建表最稳妥，结构部分（表名/列名）须拼接字符串，值部分可参数化；MySQL必须用PREPARE+EXECUTE；PostgreSQL推荐EXECUTE+format()配合%I安全处理标识符；均需校验输入、防重复、控权限与事务。
SQL Server 里用 sp_executesql 动态建表最稳妥
直接拼接字符串 + EXEC 容易被注入、参数类型难控，sp_executesql 支持参数化，哪怕建表语句里要插变量名或字段数，也能把值和结构分离。比如业务方传入表名前缀 @table_prefix，你得先校验它只含字母数字下划线，再塞进 sp_executesql 的参数列表，而不是拼进 SQL 字符串里。
常见错误现象：Msg 102, Level 15, State 1, Line 1 Incorrect syntax near '@table_name' —— 这是因为把变量直接写在 CREATE TABLE @table_name 里，SQL Server 不允许表名/列名用变量代替，必须动态拼字符串再执行。
- 表名、列名、数据类型这些「结构部分」必须拼进字符串，不能参数化
- 字段长度、默认值、约束条件里的具体值（如
VARCHAR(50)的50）可以参数化，但需提前转成字符串再拼 - 建表前务必检查
sys.tables，避免重复创建：IF NOT EXISTS (SELECT 1 FROM sys.tables WHERE name = @table_name)
MySQL 中 PREPARE + EXECUTE 是唯一可行路径
MySQL 不支持存储过程里直接用变量当表名，连 CREATE TABLE @t 都会报错 ERROR 1064 (42000)。只能靠三步走：拼好完整建表语句 → PREPARE stmt FROM @sql → EXECUTE stmt → DEALLOCATE PREPARE stmt。
使用场景：日志表按月分表（log_202409）、租户隔离表（tenant_123_orders），这类名字带动态片段的必须走 PREPARE。
-
@sql必须是用户变量（SET @sql = 'CREATE TABLE ...'），局部变量不行 - 字段定义里如果含单引号（如
DEFAULT 'N'），拼字符串时得用两个单引号转义 - 每次
EXECUTE前记得DEALLOCATE，否则可能触发ERROR 1064或内存泄漏
PostgreSQL 用 EXECUTE + format() 更安全
PostgreSQL 存储过程中不能直接用变量建表，但 EXECUTE 配合 format() 能自动处理引号和转义，比手拼字符串可靠得多。比如 EXECUTE format('CREATE TABLE %I (id SERIAL, name %s)', table_name, data_type)，%I 会安全包裹标识符，%s 插入字符串值。
容易踩的坑：用 %L 插入表名会加单引号，变成 'my_table'，导致语法错误；必须用 %I。
-
format()的%I用于表名/列名，%L仅用于字面值（如字符串默认值） - 动态字段类型（如
VARCHAR(255)）得作为字符串传入，不能用变量直接代入%s后再解析 - 建表语句太长时，
format()对嵌套括号敏感，建议拆成多段拼接再传入
所有数据库都绕不开的权限与事务陷阱
动态建表不是普通 DML，它修改数据字典，多数数据库要求 DBA 或 DDL_ADMIN 权限，普通 INSERT/SELECT 权限完全无效。而且 DDL 语句在事务中行为不一致：SQL Server 里 CREATE TABLE 会隐式提交当前事务；MySQL 在 autocommit=off 时能回滚，但 PostgreSQL 默认不允许在事务块里执行 DDL。
性能影响：频繁建表会锁系统表（如 sys.objects、information_schema），高并发下可能卡住其他查询。
- 别在循环里反复建表，先判断是否存在，不存在才建
- 生产环境禁用自动建表逻辑，至少加个开关配置或人工确认步骤
- 表结构变更比建表更危险，动态建表后别紧接着跑
ALTER TABLE，容易因锁表失败
真正麻烦的是跨环境一致性——开发库建的表，字段顺序、注释、索引策略很难自动同步到测试库。手动维护建表脚本反而更可控。
