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