当便捷战胜安全 — Schema 误删的思考

就在刚刚，新年伊始就目睹了一起惨案，某童鞋在 DBeaver 上操作了删除某个 schema，直接点了 Yes，然后就没有然后了。

问题在于：DBeaver 这类 GUI 工具在执行删除 schema 时，实际下发给数据库的 SQL 是带有 CASCADE 的，这意味着它会把该 schema 下的对象 (表、视图、函数、类型……) 全部级联删除。如果生产环境没有完善的 备份/PITR/WAL 归档等恢复链路，基本凉凉。

比如我现在要删除这个 test_schema，如果你点了 Yes，默认就给你全部级联删除了，通过 View Script 你也能看到确实是 DROPSCHEMA test_schema CASCADE;

再看一下 pgAdmin4 的交互：它把删除操作拆成了两种选择 (是否 Cascade)

并且当你选择 Cascade 时，会给出非常明确的二次确认提示⚠️：

Are you sure you want to drop the schema "test_schema" and all the objects that depend on it?

意图很明确，想执行 cascade 的人，必须要 double-check。这就是典型的 safe-by-default：宁可让用户多点两下、多看一次依赖，也不要让用户误删一整套对象。

很多 GUI 工具为了让右键删除看起来更成功 (不弹失败、不让用户再处理依赖)，就倾向于默认走 CASCADE。从产品体验/少报错的角度，这确实更省事；但从数据库安全与误操作成本的角度，这种默认行为非常不友好 —— 尤其是当操作者可能都不理解 CASCADE 的语义时。

我见

客户误删：从人因角度很正常，GUI 删除在大多数软件里意味着删掉这个节点，而不是删除这个节点以及它下面所有东西。

DBeaver 的默认/交互：它在“危险操作的默认值 + 提示强度”上偏激进，更适合资深用户自己承担后果；对企业生产环境不够贴心。

pgAdmin 的做法：更像数据库管理工具该有的态度 —— 宁可啰嗦，也别埋雷。

生产环境尽量不要用 GUI 直接执行 Drop 类操作 (drop database/schema/table)，建议走脚本评审/变更流程。

把 DROP ... CASCADE 视为高危命令：权限上限制、流程上强制二次确认。

备份与 PITR 是底线：没有可用恢复链路，就不要允许任何一键删除。

总之，慎重。