回滚脚本必须满足三条件才真正安全：全为带索引WHERE的DML、显式BEGIN与ROLLBACK包裹、不含任何DDL；否则是高危操作，Navicat中直接执行易因AUTOCOMMIT=1或分隔符问题导致无效回滚。
回滚脚本不能靠“看起来像sql”就认为安全，必须验证它真能执行、不报错、不误删、不破坏依赖关系——尤其在生产环境，一条rollback没起作用，可能比commit更危险。
为什么Navicat里直接右键“执行”回滚脚本是高危操作
Navicat默认开启AUTOCOMMIT=1，哪怕你写了ROLLBACK，只要前面没显式BEGIN或START TRANSACTION，这条ROLLBACK根本无效；它只对最近一次未提交的事务起作用，而多数回滚脚本是独立语句块，没有上下文事务可回滚。
- 脚本里写
ROLLBACK;但没BEGIN→ Navicat执行后返回“Query OK”，实际什么都没撤回 - 脚本含
DROP TABLE或TRUNCATE→ 这些DDL语句自动提交，ROLLBACK对其完全无效 - 脚本用
SET SQL_SAFE_UPDATES = 0绕过保护 → 执行时不会弹确认，删库风险直线上升 - Navicat SQL编辑器对多语句分隔符（如
DELIMITER $$）支持不稳定 → 可能只执行前半段，后半段被忽略
验证回滚脚本是否真正可执行的三步法
核心原则：不连生产库，不改真实数据，只验证语法+逻辑+事务边界。以下步骤缺一不可：
- 第一步：用
mysql -e "source /path/to/rollback.sql" --verbose在测试库（Docker实例或本地空库）运行，观察是否卡在某行、是否输出ERROR 1146（表不存在）或ERROR 1091（列已删除） - 第二步：手动包裹脚本加事务头尾：
BEGIN; -- 原始回滚脚本内容（确保不含DDL） ROLLBACK;
然后在Navicat中执行整段——右下角必须显示Transaction字样，且执行后查表确认数据未变 - 第三步：检查脚本是否混用DDL和DML。用文本搜索：
grep -iE "(drop|truncate|alter|create)" rollback.sql。若有，说明它不是纯回滚脚本，而是“重建脚本”，不能用ROLLBACK兜底
Navicat里最容易被忽略的两个事务陷阱
很多回滚失败，不是脚本写错了，而是Navicat会话状态没对齐：
-
SET AUTOCOMMIT = 0必须在每个新Query标签页里重写一次——关闭标签页后设置丢失，旧标签页仍沿用上次连接的AUTOCOMMIT值 - Navicat“执行当前语句”（快捷键
F9）只执行光标所在行，而回滚脚本往往跨多行；必须选中全部内容再按Ctrl+R（Windows）或Cmd+R（Mac），否则ROLLBACK单独执行，前面的UPDATE早已自动提交
真正的安全底线：回滚脚本必须满足这三条
如果脚本不满足任意一条，就不是回滚脚本，而是“风险操作清单”，别指望ROLLBACK能救你：
- 全由DML组成（
INSERT/UPDATE/DELETE），不含任何DDL - 每条DML前都有明确
WHERE条件，且条件字段在目标表上有索引（避免触发SQL_SAFE_UPDATES拦截） - 脚本开头有
BEGIN;，结尾有ROLLBACK;，中间无COMMIT;或隐式提交操作（如ALTER TABLE）
复杂点在于：有些“回滚”其实是用INSERT ... SELECT把旧快照插回去，这种脚本本质是正向操作，验证重点变成“目标表是否为空”“SELECT源是否存在”。别被名字骗了。
