回滚脚本必须满足三条件才真正安全：全为带索引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会话状态没对齐：

navicatmysql

Navicat For MySQL

下载

• 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源是否存在”。别被名字骗了。