rollback 对已提交事务完全无效，因其仅作用于未提交事务；补救需依赖 binlog 解析、时间点恢复或备份还原，预防则靠显式事务与权限管控。

ROLLBACK 对已提交事务完全无效，MySQL 8.0 没有“撤销已提交 DML”的原生命令。所谓“撤回”，本质是事后补救，不是回滚。

为什么 ROLLBACK 不起作用

事务一旦执行 COMMIT，修改就写入磁盘并释放 undo 日志（InnoDB 中 undo log 在事务提交后可能被快速清理或重用）。此时再执行 ROLLBACK 会报错或静默失败——它只对未提交事务有效。

• 常见错误现象：ROLLBACK; 执行成功但数据没变，其实是“回滚了一个空事务”
• 检查是否已提交：看有没有手动执行过 COMMIT，或默认 autocommit=1 下单条 UPDATE 就自动提交
• MyISAM 表根本无事务支持，ROLLBACK 永远无效

真正可用的补救手段只有三种

没有“一键撤销”，只有按场景选路径：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 从 binlog 解析还原：前提是你开启了 binlog_format = ROW 且未过期。用 mysqlbinlog --base64-output=DECODE-ROWS -v 查出误操作那条语句，手写反向 SQL（如把 UPDATE 改成对应 SET 回旧值）
• 时间点恢复（PITR）：停库 + 用全量备份 + binlog 恢复到误操作前一秒。代价高，需提前有备份策略
• 从备份还原整表/库：如果误操作范围小（比如只错删了某几行），可从最近备份中导出对应数据，再 INSERT IGNORE 或 REPLACE INTO 补回

撤销权限和撤销数据是两回事

别混淆 REVOKE 和数据回滚。前者改的是用户能做什么，后者改的是数据本身。执行 REVOKE UPDATE ON db.tbl FROM 'u'@'%'; 不会影响已经发生的 UPDATE，只是阻止后续操作。

• REVOKE 生效后，当前连接仍保留旧权限，必须重连或执行 SET ROLE NONE;
• 撤销用户所有权限不能靠 REVOKE ALL PRIVILEGES FROM ... 一步到位，要分对象级、列级、函数级逐层清理
• 若启用了 partial_revokes=ON，全局 REVOKE ALL PRIVILEGES ON *.* 会直接报错

预防永远比补救便宜

线上环境不设防地执行 DML，等于裸奔。最轻量有效的防护就是强制显式事务 + 即时核对：

• 永远在 DML 前加 BEGIN;，执行后立刻 SELECT 验证结果
• 临时关闭自动提交：SET autocommit = 0;（注意该设置只对当前会话生效）
• 复杂操作加 SAVEPOINT，比如 SAVEPOINT before_delete;，出错时 ROLLBACK TO before_delete;
• 开发/测试库开启 sql_log_bin = 0 可禁用 binlog 写入，避免干扰主库恢复链路

真正棘手的不是怎么“撤销”，而是怎么确认那条误操作到底改了什么、影响范围有多大——日志没开、备份没做、没开 ROW 格式 binlog，补救就只剩人工肉眼比对。