不能回滚。sql server默认自动提交，未显式begin transaction的update会立即永久生效；可通过select @@trancount确认事务状态，值为0即无活跃事务；savepoint仅适用于显式事务内部分回滚；已commit操作只能依赖备份、日志或快照恢复。
只有在事务未提交时，才能用 ROLLBACK 瞬间回滚；一旦 COMMIT 或自动提交生效，就无法靠事务撤销，必须依赖备份、日志或快照。
UPDATE 前没加 BEGIN TRANSACTION 就执行了，还能回滚吗？
不能。SQL Server 默认开启自动提交（autocommit = ON），每条 UPDATE 语句单独成一个隐式事务，执行完立刻永久生效。
- 检查是否还在事务中：运行
SELECT @@TRANCOUNT，返回0表示当前无活跃事务，ROLLBACK会报错The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION - 别指望“刚执行完还能撤”——只要没显式
BEGIN TRANSACTION，就没有回滚入口 - 某些客户端工具（如 SSMS）可能默认关闭自动提交，但这是界面层行为，不是 SQL Server 服务端默认设置，不可依赖
如何用 SAVEPOINT 实现有条件的部分回滚？
SAVEPOINT 允许你在大事务里设锚点，只回滚到该点，而不是整个事务。适合分阶段操作、中间验证的场景。
- 必须在
BEGIN TRANSACTION内使用，例如：BEGIN TRANSACTION; UPDATE Orders SET Status = 'Shipped' WHERE OrderID = 1001; SAVE TRANSACTION shipped_done; UPDATE Inventory SET Qty = Qty - 1 WHERE ProductID = 2001; - 若第二步出错，执行
ROLLBACK TRANSACTION shipped_done，只会撤销库存更新，订单状态仍保留 -
SAVEPOINT名称不区分大小写，但不能重复；回滚后该保存点自动失效，不可再次引用 - 注意：嵌套事务中，
SAVEPOINT不影响外层事务计数，@@TRANCOUNT不变
已 COMMIT 的 UPDATE 怎么补救？
没有通用“撤销键”，只能靠外部机制还原——而且恢复粒度、时效性、停机时间全看你的备份策略是否到位。
- 最常用路径：完整备份 + 事务日志备份 → 用
RESTORE DATABASE ... WITH STOPAT恢复到出错前一秒（要求数据库处于完整恢复模式） - 如果开了数据库快照（
CREATE DATABASE SNAPSHOT），可直接RESTORE DATABASE db_name FROM DATABASE_SNAPSHOT = 'snap_name'，秒级恢复，但快照需提前创建且占用磁盘空间 - 没备份也没快照？只能从应用日志、ETL 调度记录、或下游系统反推原始值——这不是数据库能力，是运维兜底能力
- 切记：
BACKUP LOG必须在误操作发生前已完成，否则日志链断裂，STOPAT失效
真正容易被忽略的点：事务不是保险丝，而是开关——它只对“你主动打开的那段代码”起作用。生产环境上一条裸 UPDATE 没包事务，等于把数据交出去签字画押，之后所有补救动作都是事后抢救，代价远高于事前加两行 BEGIN TRANSACTION 和 SELECT 验证。
