MySQL无全局回滚，事务仅限当前连接且须显式控制；已提交或自动提交的操作不可逆；误操作后依赖binlog解析+人工还原，但前提需开启ROW格式binlog；最可靠方案是操作前备份。
MySQL 没有全局回滚，事务只作用于当前连接
MySQL 本身不支持“撤销所有数据库更改”这种跨会话、跨时间的操作。所谓“快速撤销”，实际只能靠 ROLLBACK 回滚**当前事务中尚未提交的修改**，且仅对当前连接有效。一旦执行了 COMMIT，或者连接断开、事务自动提交（如非事务引擎或 autocommit=1），就彻底不可逆。
常见错误现象：ROLLBACK 执行后数据没变回去，其实是已经 COMMIT 了，或者操作的是 MyISAM 表（不支持事务）。
- 确认引擎：用
SHOW CREATE TABLE `table_name`查看是否为InnoDB - 检查 autocommit：运行
SELECT @@autocommit，返回1表示自动提交开启，需先执行SET autocommit = 0再开始修改 - 事务边界要手动控制：必须显式
BEGIN或START TRANSACTION，再ROLLBACK才有意义
如何在开发/测试中安全地试错并一键回退
这不是生产环境的补救手段，而是提前设计的防护策略——把可能出错的一组操作包进一个事务里，验证无误再提交。
使用场景：批量更新、多表关联修改、脚本化数据迁移前的预演。
- 开头加
START TRANSACTION，结尾用SELECT快速核对中间结果 - 确认没问题就
COMMIT；发现问题立刻ROLLBACK - 避免在事务里做耗时操作（如大表
UPDATE），否则锁表时间长，影响并发 - 注意：DDL 语句（如
ALTER TABLE）在 MySQL 中会隐式提交当前事务，导致前面的 DML 无法回滚
误删/误改后没有事务怎么办？靠 binlog 回滚是唯一可行路径
如果已经 COMMIT，又没提前备份，binlog 是最现实的恢复依据——但不是“一键回滚”，而是解析日志、反向生成 SQL、人工校验后重放。
前提条件：MySQL 开启了 binlog（log_bin = ON），且格式为 ROW（binlog_format = ROW）。
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析指定时间段的 binlog 文件 - 找到误操作对应的
DELETE或UPDATE事件，提取WHERE条件和旧值 - 手写
INSERT或UPDATE语句还原（不能直接依赖工具生成的反向 SQL，容易漏条件或错列顺序） -
binlog不保存SELECT或TRUNCATE的完整行数据，后者几乎无法精确恢复
为什么不要依赖 “撤销所有更改” 这种思路
真正容易被忽略的，是把“可逆性”当成事后补救，而不是前置约束。MySQL 的事务模型天然不支持跨连接、跨时间点的统一快照回退。
复杂点在于：你永远不确定哪些修改已提交、哪些连接还在跑、哪些表用了不同引擎、哪些操作触发了隐式提交。
更务实的做法是——在执行任何变更前，先 CREATE TABLE backup_20240520 AS SELECT * FROM target_table，或用 mysqldump 导出逻辑备份。比起琢磨怎么回滚，花两分钟备份的成本低得多，也可靠得多。
