直接执行ALTER TABLE多条语句最可靠，必须写SQL批量执行，不可依赖DBeaver图形化功能；它一次仅支持单表编辑，无批量加字段选项，且结构同步不适用于统一追加字段场景。
直接执行 ALTER TABLE 多条语句最可靠
不能依赖 DBeaver 的图形化「编辑表」功能批量操作多张表——它一次只支持单表，右键→「编辑表」→「新建列」只能作用于当前选中的那一个表。真要批量加字段，必须写 SQL 批量执行。ALTER TABLE 是唯一通用、可控、可复现的方式，所有主流数据库（MySQL、PostgreSQL、Oracle、SQL Server）都支持，只是语法细节略有差异。
常见错误现象：在 DBeaver 中选中多个表后右击，发现没有「批量编辑结构」选项；或者误以为「导出 DDL」后改写再导入能自动生效，结果执行报错或只影响第一张表。
- MySQL 用
ALTER TABLE table_name ADD COLUMN col_name TYPE [AFTER existing_col] - PostgreSQL 必须用
ADD COLUMN，不支持AFTER，顺序靠建表时定义或后续调整视图/查询逻辑 - SQL Server 支持
AFTER，但需注意IDENTITY列限制 - 执行前务必确认每张表名存在且你有
ALTER权限，否则某一条失败会中断整个脚本（除非显式开启事务并捕获异常）
用 SQL 脚本生成器快速拼出全部 ALTER 语句
手动写几十条 ALTER TABLE 容易漏、易错。推荐在 DBeaver 中用简单查询动态生成——比如你想给所有以 log_ 开头的表都加一个 tenant_id VARCHAR(32) 字段：
SELECT 'ALTER TABLE ' || table_name || ' ADD COLUMN tenant_id VARCHAR(32);' FROM information_schema.tables WHERE table_schema = 'your_db_name' AND table_name LIKE 'log_%';
把结果复制出来，检查无误后粘贴进新 SQL 编辑器执行。注意：information_schema 视图名和字段名因数据库而异：
- MySQL / PostgreSQL：用
information_schema.tables和table_schema - SQL Server：改用
sys.tables和sys.schemas - Oracle：查
user_tables或all_tables，owner对应 schema
别忘了执行前先备份关键表，或在测试库验证脚本逻辑。
避免用「结构同步」功能替代加字段
DBeaver 的「Compare → Simple Structure Compare」看着很智能，但它本质是比对两个数据库（或两个连接）之间的对象差异，然后生成目标端缺失的 DDL。它**不是为“给一批现有表统一加同一字段”设计的**。
典型翻车场景：
- 源库有 10 张表，目标库只有 5 张，同步后只给那 5 张补字段，另外 5 张被忽略
- 你改了本地开发库的 10 张表结构，想一键推到测试库，但同步工具会把「测试库多出来的其他表」也列为差异项，导致生成一堆无关 DDL
- 字段类型映射出错，比如 MySQL 的
TINYINT(1)在 PostgreSQL 同步时被转成BOOLEAN，破坏业务语义
结构同步适合环境间整体迁移，不适合定向、批量、同构的字段追加。
执行时注意事务与锁行为
ALTER TABLE ... ADD COLUMN 在多数数据库里是 DDL 操作，隐式提交，无法回滚（PostgreSQL 11+ 支持部分 DDL 在事务中执行，但加字段仍受限）。更关键的是锁表现：
- MySQL 5.6+（InnoDB）：
ADD COLUMN默认需拷贝全表（online DDL 需满足条件，如无全文索引、非虚拟列等），大表可能锁数分钟 - PostgreSQL：加普通字段几乎瞬时（只改系统表），但若带
DEFAULT值且非NULL，会触发全表扫描更新，默认值才真正写入 - SQL Server：在线操作支持较好，但仍建议避开高峰时段
所以批量执行前，最好按表大小排序，从小到大执行；带默认值的字段，先 ADD COLUMN，再用 UPDATE 分批赋值，最后加 NOT NULL 约束——这样可控性更强。
