SQL Server：事务成功后数据自动删除问题排查

嘿，这个场景我碰到过好几次，结合SQL Server的特性，给你列几个最可能的原因：

• 事务提交/回滚逻辑错误
  这是最常见的坑，得仔细检查存储过程里的事务控制细节：

  • 是不是在TRY块执行完所有插入后，漏掉了COMMIT TRANSACTION？如果事务没提交，一旦会话结束，SQL Server会自动回滚这个事务，数据自然就消失了。
  • 有没有在CATCH块里不管错误类型都直接执行ROLLBACK？比如有些警告级别的错误（比如开启IGNORE_DUP_KEY后的主键重复）不会触发CATCH，但如果调用存储过程的外层还有事务（比如应用程序用了TransactionScope），外层事务回滚会把存储过程里的操作也一并撤销。
  • 还要注意SQL Server的“伪嵌套事务”特性：嵌套事务只有最外层的COMMIT才会真正提交，只要中间有一次ROLLBACK，整个事务都会被回滚，不管嵌套层级。

• 隐藏的删除逻辑（触发器/后续操作）
  这个很容易被忽略，得排查表和存储过程的隐含操作：

  • 检查插入的目标表有没有DELETE触发器或者INSTEAD OF INSERT触发器？比如有些触发器会在插入后自动清理重复数据，或者业务逻辑要求插入后删除旧数据，如果触发器逻辑有漏洞，可能误删刚插入的数据。你可以用sp_helptrigger [表名]查看触发器列表，或者直接查看触发器的定义脚本。
  • 存储过程里有没有在插入之后，跟着带条件的DELETE或UPDATE语句？比如某个分支逻辑触发了删除，你可能没注意到这个分支的执行条件刚好命中了刚插入的数据。

• 外部进程/定时任务的清理
  有没有其他程序在悄悄操作这些表？比如：

  • 有没有SQL Agent作业定期清理表数据？比如每天凌晨删除7天前的数据，如果你的插入数据刚好符合清理条件，就会被自动删掉。
  • 应用程序的其他模块有没有调用删除接口？比如前端误操作、后台定时任务的逻辑错误，导致刚插入的数据被意外删除。

• 并发与隔离级别问题
  这种情况比较隐蔽，得结合业务的并发场景排查：

  • 如果你的应用程序用了较低的隔离级别（比如READ UNCOMMITTED），可能会看到其他未提交事务的插入数据，当那个事务回滚后，你之前看到的数据就“消失”了——其实这些数据从来没真正提交过。
  • 有没有其他事务在执行批量删除，刚好覆盖了你插入的数据？比如某个大删除事务在你插入之后执行，且没有加行级锁，导致你的数据被误删。

• 数据库恢复/同步问题

  • 有没有人误操作恢复了数据库备份？比如恢复到了插入数据之前的时间点，直接覆盖掉了新插入的数据。
  • 如果数据库配置了镜像、复制或者Always On，有没有同步异常？比如复制过程中订阅端的删除操作同步到了发布端，或者镜像切换时丢失了未同步的数据。

• 应用程序端的事务控制
  有时候问题不在存储过程本身，而在调用它的应用程序：

  • 比如应用程序用了TransactionScope或者ADO.NET的SqlTransaction，调用存储过程后没有调用Complete()或Commit()，反而触发了回滚，导致存储过程里的插入操作被撤销。
  • 应用程序有没有重复调用存储过程，或者调用了错误的存储过程（比如一个带删除逻辑的同名存储过程）？

内容的提问来源于stack exchange，提问作者Ahsan 02