Navicat 不拦截无条件 DELETE 是因它仅转发 SQL 至 MySQL，而 MySQL 默认允许执行；需通过 SQL_SAFE_UPDATES、权限控制或脚本预检等手段防护。
Navicat 里没写 WHERE 的 DELETE 为什么会直接执行
navicat 本身不拦截无条件 delete from table_name 这类语句——它只负责把 sql 发给 mysql，而 mysql 默认允许执行。只要连接用户有 delete 权限，命令一提交就删，不会弹窗确认，也不会自动加事务保护。
- Navicat 的「查询」编辑器和「运行SQL文件」都默认关闭自动事务（
AUTOCOMMIT=1），意味着每条DELETE立即生效，无法回滚 - 即使你在「工具 → 选项 → SQL 编辑器」里勾了「执行前提示确认」，它也只对 Navicat 自带的图形化操作（比如右键删行）起作用，对手动写的
DELETE语句完全无效 - 如果 SQL 文件里混着
DELETE和INSERT，用「运行SQL文件」导入时，Navicat 不会做语法分析，照样一条条发给服务器
强制加 WHERE 的实操办法：用 MySQL 层级限制
最可靠的方式不是依赖 Navicat 界面设置，而是从数据库权限和配置入手，让无条件 DELETE 根本跑不通。
- 给日常使用的账号收回
DELETE权限，只授予SELECT、INSERT、UPDATE—— 真要删数据时，临时授权或换高权限账号 - 在 MySQL 配置文件（
my.cnf或my.ini）里加一行：sql_mode = STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ERROR_FOR_DIVISION_BY_ZERO，虽然不直接拦DELETE，但配合应用层逻辑能减少误操作蔓延 - 启用 MySQL 8.0+ 的
safe-updates模式（实际叫sql_safe_updates）：登录后执行SET SQL_SAFE_UPDATES = 1;，此时任何DELETE或UPDATE必须带WHERE或LIMIT，否则报错Error Code: 1175. You are using safe update mode... - 把这个设置写进用户级配置：在 MySQL 用户的
~/.my.cnf（Linux/macOS）或%USERPROFILE%\my.ini（Windows）里加[mysql]段，写入init-command="SET SQL_SAFE_UPDATES=1;"，这样每次 Navicat 连接都会自动启用
Navicat 本地防护：别信“提示框”，得靠脚本预检
界面提示不可靠，但你可以用外部脚本在执行前扫一遍 SQL 内容，发现裸 DELETE FROM 就中断。
- 写个 Python 脚本（或 PowerShell），用正则匹配
^\s*DELETE\s+FROM\s+\w+\s*;?\s*$（注意忽略大小写和空格），匹配到就拒绝提交 - Navicat 的「批处理作业」不支持预检，但你可以把 SQL 文件先丢给脚本过一遍，再调用
navicat.exe /batchjob执行 - 如果必须用「运行SQL文件」，提前用文本编辑器全局搜索
DELETE FROM，确认每处都有WHERE或LIMIT；特别注意嵌套子查询里的DELETE，比如DELETE FROM t1 WHERE id IN (SELECT ...)是安全的，但DELETE FROM t1;就危险
真删数据前必须做的三件事
哪怕开了 SQL_SAFE_UPDATES，也不能跳过人工核验。最容易被忽略的是备份方式本身是否可用。
- 执行前先用
SELECT COUNT(*) FROM table_name WHERE ...确认要删的行数，而不是只看DELETE语句长得像不像对 - 别依赖 Navicat「备份」功能当救命稻草——它的物理备份（
.nbu）恢复慢、跨版本兼容差；优先用mysqldump --single-transaction导出快照，存为backup_20260727_table.sql这种带时间戳的文件 - 如果目标表有外键，
DELETE可能触发级联删除，而SQL_SAFE_UPDATES不拦这个。务必先查SELECT TABLE_NAME,COLUMN_NAME,CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME='your_table';
