sql server中sp_executesql动态添加列报“对象名无效”主因是参数不支持传入表名/列名等标识符，必须用quotename()手动拼接并校验存在性，否则解析失败。
SQL Server 中用 sp_executesql 动态添加列时为什么报错“对象名无效”？
直接拼接 ALTER TABLE ... ADD 语句却提示表不存在，通常不是表真丢了，而是执行上下文里没识别到变量里的表名。SQL Server 不允许在 DDL 语句中直接用参数化变量传入表名或列名——sp_executesql 的参数只支持值（如 @value），不支持对象标识符（如 @table_name）。
必须手动拼接对象名，但要严格校验，否则引发 SQL 注入或语法错误：
- 用
QUOTENAME(@table_name)包裹表名和列名，自动加方括号并转义特殊字符（比如带空格或连字符的表名） - 先查
sys.tables确认表存在：IF NOT EXISTS (SELECT 1 FROM sys.tables WHERE name = @table_name) - 避免把用户输入原样拼进 SQL 字符串——哪怕只是内部管理用，也得过一遍
QUOTENAME
DECLARE @sql NVARCHAR(MAX) = N'ALTER TABLE ' + QUOTENAME(@table_name) +
N' ADD ' + QUOTENAME(@column_name) + N' ' + @data_type;
EXEC sp_executesql @sql;
MySQL 存储过程中动态加字段为何总提示 “ERROR 1064”？
MySQL 的存储过程不支持直接用变量替换列名或类型，ALTER TABLE tbl ADD COLUMN col INT 这类语句里的 col 和 INT 都不能是变量。必须用 CONCAT() 拼字符串，再用 PREPARE/EXECUTE 执行。
常见翻车点：
-
CONCAT()拼出的 SQL 字符串里漏了空格，比如CONCAT('ADD COLUMN',@col,'INT')→ADD COLUMNageINT，直接语法报错 - 没处理单引号：如果
@data_type是'VARCHAR(50)'，拼出来会多一层引号，变成VARCHAR(50)'，报错 - 执行完没
DEALLOCATE PREPARE，长期运行可能耗尽语句句柄
SET @sql = CONCAT('ALTER TABLE ', @table_name, ' ADD COLUMN ', @column_name, ' ', @data_type);
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
PostgreSQL 里想用 EXECUTE 动态加字段，但提示 “relation does not exist”
PostgreSQL 的 EXECUTE 支持参数化对象名，但仅限于 format() 函数配合 %I（identifier）占位符——不能用 %L（literal），否则加单引号导致识别为字符串字面量。
关键细节：
-
%I自动加双引号并转义，安全处理大小写和特殊字符；%L加单引号，只适合值，不适合表名/列名 - 必须用
pg_class或information_schema提前验证表是否存在，否则EXECUTE报错就中断过程 - 字段默认值若含表达式（如
NOW()），需用%s拼进去，不能当参数传
EXECUTE format('ALTER TABLE %I ADD COLUMN %I %s',
table_name, column_name, data_type);
跨数据库做动态结构变更，哪些地方最容易被忽略？
不同数据库对“动态 DDL”的容忍度差异极大，不是语法改一改就能迁移的。最常踩的隐性坑：
- 事务行为：SQL Server 的
ALTER TABLE在显式事务里能回滚；MySQL 5.7+ 的 DDL 默认隐式提交，加字段会自动提交当前事务，无法回滚 - 锁粒度：PostgreSQL 加字段默认锁全表（
ACCESS EXCLUSIVE），大表操作期间读写全阻塞；MySQL 8.0+ 的ALGORITHM=INPLACE可减少锁，但得显式写 - 权限检查：MySQL 要求
ALTER权限；PostgreSQL 要求对表有OWNER或ALTER权限；SQL Server 要求ALTER权限且不能是只读数据库
真正上线前，得在目标环境用真实数据量压测一次加字段耗时和锁表现——文档写的“支持”，不等于你这张 2TB 表能扛住。
