不能回滚。UPDATE在自动提交模式下执行完毕后数据已永久写入，ROLLBACK无效；必须提前显式开启事务并设置SAVEPOINT才能部分回滚，事后无法补救。
不能回滚。UPDATE 语句一旦在自动提交模式下执行完毕，数据就永久写入，ROLLBACK 无效——这不是权限或语法问题，而是事务生命周期已结束。
UPDATE 执行后没加事务，还能 ROLLBACK 吗
不能。MySQL、PostgreSQL、SQL Server、SQLite 默认都开启 autocommit=1，意味着每条 UPDATE 单独成事务，执行完立刻提交。此时再运行 ROLLBACK，数据库会返回 “no transaction in progress” 或直接忽略。
常见误操作场景：
- 在 Navicat / DBeaver / MySQL Workbench 中直接右键执行 SQL，没手动关掉「自动提交」
- 用 Python 的
cursor.execute("UPDATE ...")但没调用conn.begin()或设autocommit=False - 命令行里用
mysql -e "UPDATE ..."，这种一次性执行必然自动提交
SAVEPOINT 不是后悔药，是必须提前埋的检查点
SAVEPOINT 只在显式事务内有效，且必须在 UPDATE 前定义。它不是“执行完再补一个”，而是你主动控制回退边界的手段。
正确顺序只有这一种：
-
BEGIN或START TRANSACTION（开启事务边界） -
SAVEPOINT sp_before_update（命名合法，不含空格或特殊符号） -
UPDATE ...（执行修改） - 出错时：
ROLLBACK TO sp_before_update；确认无误：COMMIT或RELEASE SAVEPOINT sp_before_update
典型失效情况：
- 建了
SAVEPOINT sp1，却写ROLLBACK TO sp_1→ 报错SAVEPOINT does not exist - 事务中穿插了
ALTER TABLE→ MySQL InnoDB 隐式提交，所有SAVEPOINT清空 - 客户端崩溃或连接中断 → 服务端可能自动回滚，但
SAVEPOINT状态不保留
已提交的 UPDATE 还能恢复吗？取决于有没有 binlog 或完整备份
事务提交后，Undo Log 被清理，ROLLBACK 彻底失效。恢复唯一路径是外部机制：
- MySQL：需开启
binlog_format = ROW且log_bin = ON，再用binlog2sql解析日志，生成反向UPDATE或原值还原语句 - SQL Server：依赖完整恢复模式 + 完整备份 + 日志备份链；需用
RESTORE DATABASE ... WITH STOPAT回退到误操作前时间点 - PostgreSQL：靠
pg_wal归档 + 基础备份，配合recovery_target_time实现时间点恢复
关键前提常被忽略：
- MySQL 的
binlog默认不开启，开了也可能设为STATEMENT格式（无法精确还原） - SQL Server 新建数据库默认是完整恢复模式，但很多测试库被手动改成简单模式，日志无法备份
- 所有方案都要求「误操作前至少有一次完整备份」，临时起意去备份已经晚了
最易被低估的一点：回滚能力不是数据库自带的“开关”，而是你每次执行 UPDATE 前，是否记得敲下 BEGIN、是否确认工具里 autocommit 是关着的、是否查过 binlog 或备份状态——这些动作不在报错之后，而在光标移向回车键之前。
