靠“SET SQL_SAFE_UPDATES = 1; SET AUTOCOMMIT = 0;”双命令开头最有效：前者强制WHERE须走索引，否则报错；后者使DML暂存可回滚；二者缺一不可，且每次新标签页均需重输。
为什么默认不弹确认框——Auto-Commit 关闭后仍需手动加防护
navicat 默认开启 autocommit=1，delete、update 一敲回车就永久生效，根本没机会弹窗确认。即使你按教程关掉了连接级「自动提交」，navicat 也不会自动弹出“确定要删除 2345 行吗？”这类对话框——它只把事务控制权交给你，不替你做判断。
真正起效的确认流程：SET SQL_SAFE_UPDATES + 手动事务组合
靠图形界面开关或快捷键拦截危险操作不可靠，必须用 MySQL 原生命令建立双保险：
-
SET SQL_SAFE_UPDATES = 1;：强制要求UPDATE/DELETE必须带有效WHERE（能命中索引），否则直接报错ERROR 1175，连事务都不进 -
SET AUTOCOMMIT = 0;：让所有 DML 进入暂存状态，必须显式COMMIT或ROLLBACK - 两行命令必须写在生产库 SQL 编辑器最开头，每次新标签页都要重输——它不继承、不记忆、不跨标签页
执行时怎么确认？看 ROW_COUNT() 和状态栏，别信“执行成功”提示
光看 Navicat 底部弹出的绿色“执行成功”毫无意义，真正可信的只有两个信号：
- 执行
DELETE FROM users WHERE id > 1000;后，立刻跟一句SELECT ROW_COUNT();—— 返回值是具体影响行数，不是“0 rows affected”这种模糊提示 - 右下角状态栏必须显示
Transaction字样，且颜色为蓝色（非灰色）；灰色代表当前会话仍处于自动提交状态，ROLLBACK无效 - 如果
ROW_COUNT()返回异常大值（比如全表行数），立刻停手，先查EXPLAIN确认WHERE是否走索引
容易被忽略的失效场景：驱动层绕过、连接参数覆盖
有些情况会让上述设置形同虚设：
- MySQL 8.0+ 使用 X DevAPI 连接时，客户端设置的
AUTOCOMMIT可能被服务端忽略，验证方法：执行SELECT @@autocommit;，返回1就说明没生效 - Navicat 连接属性 → 「高级」→ 勾选了「使用 MySQL 兼容模式」，可能悄悄注入
NO_ZERO_DATE等限制，间接干扰SQL_SAFE_UPDATES行为 - 通过「运行 SQL 文件」导入脚本时，
SET命令只对当前语句生效，不会延续到后续语句——必须把SET写在脚本第一行，且每条 DML 后手动加SELECT ROW_COUNT();
WHERE 条件是否真的能命中索引。哪怕写了 WHERE status = 'done'，如果 status 字段没建索引，SQL_SAFE_UPDATES 不拦，ROW_COUNT() 显示的是全表扫描行数，回滚也救不回性能损失。
