很多事故其实是「执行前没人拦一下」。一次 UPDATE 少个 WHERE、一条全表扫描的 SELECT、一个没索引的 JOIN——等线上告警响了代价已经付出去了。有没有办法把这些风险挡在「执行」之前这正是 PawSQL Client for DBeaver 这个插件要做的事。为什么总是执行完才后悔做开发或 DBA下面这些场景你多半不陌生在生产库手滑执行了一条危险 DDLDROP/TRUNCATE一按就生效一条大表查询过滤条件没走索引一执行就是全表扫描同事的 SQL 满屏SELECT *还没LIMIT几百万行直接拉爆内存慢查询、长事务、误操作……多数数据库事故在 SQL 真正执行之前就已经注定了。执行完才后悔「当时要是有人提醒一句就好了」 一个装在 DBeaver 里的「体检开关」PawSQL Client 是 DBeaver 的一个插件。装上它你的 SQL 编辑器里就多了一道执行前审核你按下「执行」之前SQL 先交给 PawSQL 做一次静态规则分析再按风险决定放行还是让你确认。不用离开 DBeaver不用额外操作——体检就发生在你最熟悉的编辑器的日常操作里。流程就三步⚙️ 三种模式按你的节奏来审核强度不是一刀切配置页里自己选模式行为适合关闭不拦截维持原状不想被任何机制打扰提醒执行前弹窗询问「送审 / 直接执行 / 取消」想保留自主但偶尔想查一下强制执行前自动送审高风险必须确认生产环境、团队规范、新人防错另外还有白名单把某个数据源如开发库加进白名单后它的 SQL 在所有模式下都直接放行——既守住生产又不烦日常开发。⚠️ 风险不是一刀切按严重级别判定不同违规的「危险程度」完全不同PawSQL 给每条规则都标了严重级别级别含义例子Critical严重违规可能引发问题无主键/无索引的大表过滤、危险 DDLWarning警告级通常影响性能过滤条件未用索引列Info提示级通常规范问题SELECT *、缺少LIMIT默认拦截级别是 WarningCritical 和 Warning 需要你确认Info 直接放行。关键是——阈值你自己定。想更严就调到 Critical想更松就放到 Info全看团队容忍度。 审核详情不仅要「拦」还要「讲清楚」拦截不是目的让开发者理解风险才是。高风险 SQL 被拦下后审核详情页会告诉你顶部红色风险条这个 SQL 的风险级别是什么违规表格哪些规则被触发、严重程度、对应的 SQL 片段推荐索引 / 查询改写有优化空间就直接给你方案你不是被一句冷冰冰的「已阻止」挡住而是拿到一份可视化的诊断报告然后自己决定改一改再执行还是确认没问题、点「仍要执行」。点击「仍要执行」才执行不点不执行——决定权始终在你手里。⚡ 为什么是静态分析执行前审核特意不做性能验证What-If只跑静态规则分析。原因很简单快几秒钟出结果不拖慢工作流零副作用不真正执行、不建索引、不碰数据覆盖面广规则引擎能抓到大量约定俗成的「坏味道」需要深度的 What-If 验证、索引性价比评估时再用插件的一键优化功能——审核负责「拦截」优化负责「诊断」各司其职。 不止 DBeaverPawSQL Client 不止有 DBeaver 版VS Code、JetBrains上也能装。同一套审核规范无论你在哪个工具里写 SQL得到的都是同一套风险判断。 一分钟装好在 DBeaver 里安装PawSQL Client插件见安装文档[INSTALL.md]偏好设置 → PawSQL Client →SQL 执行审核选「强制」拦截级别选「Warning」或按需调整从此每次执行前SQL 自动体检。给你的 DBeaver 装上 PawSQL Client让每一条 SQL 在执行前都过一遍体检。