启用“执行前确认”需手动开启，路径为文件→选项→查询→勾选；它仅拦截右键等图形化操作，不拦截查询窗口中直接执行的SQL；有效防护需叠加三层：开启该功能、生产环境禁用直接运行DDL/DML、DBA配置权限限制。
启用“执行前确认”必须手动打开，它默认是关闭的
Navicat 不会在你安装完就自动弹出确认框——哪怕你刚点下 DROP TABLE 或 DELETE FROM。这个开关藏在全局设置里，不主动翻找，90% 的人根本不知道它存在。一旦团队里有人习惯性右键删表、批量清数据，又没开确认，一次手滑就是线上事故。
操作路径：文件 → 选项 → 查询 → 勾选“执行前确认”（注意不是“查询编辑器”里的那个局部开关）。勾上之后，所有通过右键菜单、工具栏按钮或快捷键触发的危险操作（比如清空表、删除视图、执行含 TRUNCATE 或 DROP 的脚本）都会弹窗让你点“是”才能继续。
“执行前确认”只拦界面操作，不拦 SQL 窗口里直接运行的语句
这是最容易被忽略的盲区：你在查询编辑器里手写 DROP DATABASE test; 然后按 F6 运行，它不会弹确认框。因为这个功能只作用于 Navicat 封装好的图形化动作（如右键 → “清空表”），不干预你手写的任意 SQL。
所以真正有效的防护要叠加两层：
- 必须开启
执行前确认拦住高频误操作路径 - 团队统一约定：生产环境禁止在查询窗口直接运行 DDL/DML，所有变更走
SQL 文件 + 审批流程 - DBA 在数据库侧配置权限限制，比如对
prod_*库禁用DROP和TRUNCATE权限，让语句直接报错
敏感操作二次确认在 Navicat Premium 17 里才完整支持
基础版 Navicat for MySQL 只有“执行前确认”这一个开关，而 Premium 17 新增了更细粒度的 敏感操作二次确认，可单独控制以下行为：
-
批量删除行（带 WHERE）—— 防止 WHERE 写错导致全表删光 -
清空整个表—— 比“执行前确认”更明确的语义提示 -
删除数据库/表/视图—— 弹窗会显示对象名和影响行数预估（如果能查到）
开启位置：文件 → 选项 → 安全 → 勾选对应项。注意：该功能依赖数据库的元数据查询能力，某些低权限账号可能看不到行数估算，但确认弹窗本身仍生效。
确认弹窗不能替代权限隔离和备份机制
再多次确认，也防不住故意删库的人，更防不住脚本里循环执行 DELETE 的逻辑错误。真正的防线是三层：
- 数据库账号必须按环境严格区分，
prod账号禁用DROP/TRUNCATE，只给SELECT/INSERT/UPDATE（且 UPDATE 带WHERE校验） - 所有连接配置强制启用
SSL或SSH 隧道，防止中间人窃取凭证 - 每日自动备份必须存在且验证过可恢复，
Navicat 作业调度里设好失败邮件告警
确认弹窗只是最后一道“防手抖”的闸门，不是安全方案的全部。跳过权限收口和备份验证，只靠点“确定”来保命，迟早出事。
