DBeaver 不支持无锁编辑表结构，ALTER TABLE 是否锁表取决于数据库引擎；PostgreSQL 改字段类型常触发全表重写并加 ACCESS EXCLUSIVE 锁；MySQL 8.0+ 部分操作支持 ALGORITHM=INSTANT/INPLACE，但需手动指定；安全实践是先生成并审查 SQL、评估表大小、禁用图形界面直接保存、设置执行超时。
直接说结论：DBeaver 本身不提供“无锁编辑表结构”的魔法，ALTER TABLE 类操作在 PostgreSQL 或 MySQL 中是否锁表，取决于数据库引擎行为，不是 DBeaver 能绕开的。你真正能控制的，是「何时执行」「用什么方式执行」「执行前是否评估风险」。
PostgreSQL 中改字段类型为什么必锁表？
当你在 DBeaver 的表编辑界面点“保存”修改列类型（比如 numeric(64,30) → numeric(64,5)），DBeaver 实际生成并执行的是类似这样的语句：
ALTER TABLE orders ALTER COLUMN amount TYPE numeric(64,5);
PostgreSQL 在执行这类类型变更时，若新类型无法通过隐式转换安全适配（例如精度缩小、类型不兼容），就会触发全表重写——它必须逐行读取旧数据、转换、写入新格式，再重建索引。这个过程需要 ACCESS EXCLUSIVE 锁，阻塞所有并发访问。
- 不是 DBeaver 的 bug，是 PostgreSQL 的设计约束
-
USING子句可以指定转换逻辑，但不改变锁级别 - 即使只改
COMMENT或默认值（SET DEFAULT），通常不锁表；但改类型、长度、非空约束（SET NOT NULL）大概率会锁
MySQL 8.0+ 的在线 DDL 能帮你省多少事？
如果你连的是 MySQL 8.0 或更新版本，部分 ALTER TABLE 操作支持 ALGORITHM=INSTANT 或 ALGORITHM=INPLACE，能显著降低锁强度。但 DBeaver 默认不加这些提示，它生成的语句就是裸 ALTER。
- 手动改语句才有效：比如
ALTER TABLE users MODIFY COLUMN name VARCHAR(100) ALGORITHM=INSTANT; - 仅限特定操作：加列、删列、改列名、改注释等可能瞬时完成；改类型（如
VARCHAR长度缩小时）仍可能需要INPLACE并短暂锁表 - 务必查官方文档确认你的具体操作是否支持在线 DDL，别凭经验猜
在 DBeaver 里安全改结构的实操习惯
别依赖图形界面一键保存。把 DBeaver 当成一个带元数据感知的 SQL 编辑器来用，而不是“傻瓜建表工具”。
- 右键表 → “生成 SQL” → “DDL”：先看它打算怎么建/改，确认语句内容，再复制到新 SQL 编辑器里手动调整
- 对大表操作前，先执行
SELECT pg_size_pretty(pg_total_relation_size('table_name'));（PostgreSQL）或SHOW TABLE STATUS LIKE 'table_name';（MySQL）估算大小 - 生产环境严禁直接在 DBeaver 图形界面点“保存”改结构；必须走审核流程 + 带超时和回滚方案的脚本
- 开启 DBeaver 的「SQL 执行超时」设置（窗口 → 首选项 → 数据库 → SQL 编辑器 → 执行超时），避免一个卡住的
ALTER挂住整个连接池
最常被忽略的一点：DBeaver 的“编辑表”功能本质是便利性封装，它掩盖了底层 DDL 的真实代价。你以为在点按钮，其实数据库正在重写三千万行——而那个进度条，只是客户端在等服务端返回，不代表操作轻量。
