DBeaver 默认允许执行 DDL，因其本质是JDBC客户端，不干预权限校验；禁止DDL需靠数据库账号权限控制（如仅授DML权限）、DBeaver中启用“Confirm execution of DDL statements”弹窗确认，并配合命名规范与代理层拦截。
为什么 DBeaver 默认允许执行 DDL，但你不能靠它来“禁止” DDL
DBeaver 本身没有“禁止 DDL 执行”的开关或权限策略功能。它只是一个 JDBC 客户端，所有 SQL（包括 CREATE、ALTER、DROP）最终都由数据库服务端决定是否允许执行。DBeaver 只负责把语句发过去，不参与权限校验——那是 MySQL、PostgreSQL 等数据库自身的用户权限体系在管的事。
所以想“禁止 DDL”，核心不是调 DBeaver 设置，而是控制数据库账号权限 + 配合客户端行为约束：
- 给开发/测试账号只授予
SELECT、INSERT、UPDATE、DELETE权限，明确不授CREATE、ALTER、DROP、INDEX等 DDL 相关权限 - 在 DBeaver 连接配置里勾选
Auto-commit（默认开启），但这只是让每条语句自动提交，并不能阻止 DDL 发出；反而可能让 DDL 更隐蔽地生效 - 避免在连接属性中启用
allowUserVariables或useSSL=false这类放宽限制的参数，它们虽不直接放行 DDL，但可能降低整体安全水位
如何在 DBeaver 中降低误执行 DDL 的风险
即使权限已收紧，人仍可能手滑敲错。DBeaver 提供几个实操级防护点：
- 关闭 SQL 编辑器右上角的
Execute all statements按钮（图标为多个竖线），改用Execute current statement（单行执行），避免一不小心把注释掉的DROP TABLE也执行了 - 在连接设置的
SQL Execution标签页中，勾选Confirm execution of DDL statements—— 这是 DBeaver 少数真正能拦截 DDL 的地方，每次执行CREATE/ALTER前会弹窗确认 - 把高危操作（如
DROP、TRUNCATE、ALTER TABLE ... DROP COLUMN）加入 DBeaver 的SQL Templates并标记为“需二次确认”，利用模板机制形成心理提示 - 不要在生产环境连接里保存密码，强制每次连接手动输入——多一次输入，就多一次重新审视当前连接目标的机会
DDL 隐式提交导致事务失效，DBeaver 里怎么察觉
这是比“禁止 DDL”更实际的问题：你在 DBeaver 里写了个事务块，中间夹了一条 ALTER TABLE，结果 ROLLBACK 不起作用，数据已经落地。这不是 DBeaver 的 bug，是 MySQL 的行为规范。
关键识别信号：
- 执行完 DDL 后，DBeaver 底部状态栏的事务指示器（显示
TX: ON或类似）会立刻变成TX: OFF - 执行
SELECT @@in_transaction;返回0（MySQL 8.0+），说明事务已被隐式终止 - 如果之前设过
SAVEPOINT，执行 DDL 后再ROLLBACK TO SAVEPOINT会报错Unknown savepoint
此时唯一补救方式是立即执行反向 DML（比如刚插的数据，赶紧 DELETE 回去），而不是寄希望于回滚。
真正需要禁止 DDL 的场景，该怎么做
如果你管理的是共享开发库，或要给实习生/外包人员开只读账号，光靠 DBeaver 设置远远不够：
- 数据库侧必须建专用账号，例如：
GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'dev_ro'@'%'; FLUSH PRIVILEGES; - 在 MySQL 8.0+ 中，可进一步用
REQUIRE SQL TID或角色（ROLE）隔离权限，比 GRANT 更易维护 - DBeaver 工作空间里，对这类只读连接统一命名为
[RO] xxx，并在连接描述里写明“严禁 DDL”，靠命名和文档形成软约束 - 真要硬隔离，得上代理层（如 ProxySQL、MaxScale）或数据库防火墙（如 MariaDB MaxScale 的 query rules），在协议层拦截 DDL 流量——DBeaver 自身做不到
记住：DBeaver 是手电筒，不是门锁。它能帮你照清 DDL 在哪、何时执行、有没有生效，但关不上那扇门。门锁得装在数据库上，而且得配好钥匙（权限）。
