不能回滚。UPDATE在自动提交模式下执行后数据已永久写入，ROLLBACK无效；必须提前开启事务并设置SAVEPOINT才能回退，事后无法补救。
UPDATE 执行后没加事务，还能回滚吗
不能。一旦 UPDATE 在自动提交模式下执行完毕（比如 MySQL 默认、psql 默认、大多数 GUI 工具默认），数据就永久写入磁盘，ROLLBACK 无效，SAVEPOINT 更无从谈起。
关键不是“怎么回”，而是“有没有提前留退路”。SAVEPOINT 不是后悔药，是主动设的检查点，必须在修改前就开启事务并定义它。
- MySQL / PostgreSQL / SQLite 都要求先
BEGIN或START TRANSACTION，再SAVEPOINT sp1 - Oracle 使用
SAVEPOINT sp1，但同样依赖显式事务，不支持对已提交语句补救 - 如果用的是 Navicat、DBeaver、MySQL Workbench 等工具，确认「自动提交」是否关闭——多数工具默认开着，一执行就提交
正确使用 SAVEPOINT 的三步顺序
顺序错一步，SAVEPOINT 就失效。常见错误是先 UPDATE 再建 SAVEPOINT，或建了不指定名字就 ROLLBACK TO。
-
BEGIN（或START TRANSACTION）——必须第一步，开启事务边界 -
SAVEPOINT sp1——命名要合法（不能含空格、特殊符号），建议用有意义的简名如sp_before_user_status_update - 执行
UPDATE，出问题时运行ROLLBACK TO sp1；确认没问题就RELEASE SAVEPOINT sp1或直接COMMIT
示例：
START TRANSACTION; SAVEPOINT sp_users; UPDATE users SET status = 'archived' WHERE id = 123; -- 发现条件写错了，赶紧撤 ROLLBACK TO sp_users; -- 后续可重试或查证 COMMIT;
ROLLBACK TO SAVEPOINT 失效的典型场景
不是语法对就一定管用。下面这些情况会让 ROLLBACK TO sp1 报错或静默失败：
-
SAVEPOINT名字拼错，比如建了sp1却写ROLLBACK TO sp_1→ 报错SAVEPOINT does not exist - 事务中途执行了 DDL（如
ALTER TABLE），某些数据库（如 MySQL InnoDB）会隐式提交当前事务，所有 SAVEPOINT 清空 - 连接断开或客户端崩溃，未
COMMIT也未ROLLBACK，服务端可能自动回滚，但 SAVEPOINT 状态已丢失 - 嵌套事务不被支持（如 MySQL 不支持真正的嵌套事务），
SAVEPOINT是唯一模拟方式，但ROLLBACK TO只能回退到本层事务内的点
没有 SAVEPOINT 时的紧急补救思路
已经 UPDATE 并提交？别刷新页面，立刻做三件事：
- 查
information_schema.TABLES或数据库日志权限：有些生产库开了binlog（MySQL）或wal_level = logical（PostgreSQL），可解析日志还原，但需要 DBA 权限和原始 binlog/wal 文件 - 看有没有备份快照：例如 pg_dump 时间点备份、MySQL Percona XtraBackup、或云数据库的自动快照（阿里云 RDS、AWS RDS 快照恢复粒度通常是整库/实例）
- 用业务逻辑反推：如果更新字段有规律（如把
status全改成draft），且原值可推测（比如只影响最近 1 小时创建的记录），可用SELECT+INSERT INTO ... SELECT或临时表修复，但需谨慎验证条件
真正可靠的“撤销”，永远发生在执行前——事务控制不是高级技巧，是写任何非只读 SQL 的基础动作。
