SQL Server 2014随机删除记录？ASP.NET MVC应用异常排查

碰到这种无用户操作却莫名丢数据的问题确实闹心，结合你的架构（Web与DB分离、EF6），我整理了几个高概率的排查方向，你可以逐一核对：

• EF6实体状态误操作
  这是最常见的坑之一：

  • 有没有在批量处理（比如循环更新、导入导出）时，不小心把实体的状态标记为EntityState.Deleted，之后调用SaveChanges()时一并提交了删除操作？比如某些逻辑里误写了context.Entry(entity).State = EntityState.Deleted，或者链式调用了dbSet.Remove(entity)却没做条件校验。
  • 有没有使用ExecuteSqlCommand或FromSql执行原生SQL时，拼接了错误的删除语句（比如漏加WHERE条件，或者条件判断逻辑错误）？EF的参数化查询能防注入，但手动拼接SQL很容易出这种问题。

• SQL注入攻击
  即便用了EF，如果存在以下情况也可能被注入：

  • 部分业务逻辑用了原生SQL拼接（比如动态生成查询/删除语句时直接拼用户输入），攻击者通过构造特殊输入触发删除操作。
  • 应用的数据库账号权限过大（比如拥有db_owner权限），一旦被注入，攻击者能执行任意删除语句。

• 后台定时任务/第三方服务误操作

  • 有没有配置Hangfire、Quartz这类定时任务？比如原本是清理过期数据的任务，却因条件写错（比如把CreatedTime < 过期时间写成了CreatedTime > 过期时间，或者直接没加过滤条件），导致批量删除有效数据。
  • 是否有其他后台服务（比如数据同步工具、ETL脚本、测试环境的调试程序）连接了生产数据库？这类服务的逻辑错误很容易导致无感知的数据删除。

• 数据库层面的隐性操作
  你说没发现存储过程、触发器，但可以再仔细排查：

  • 有没有禁用或失效的触发器？比如之前创建过删除触发器，后来被禁用但又意外启用，或者触发器的逻辑有bug（比如关联表删除时连锁删除了主表数据）。
  • 数据库账号的操作日志有没有排查？比如SQL Server可以查看事务日志（用fn_dblog函数或第三方日志分析工具），能追踪到具体的删除语句、执行时间和操作账号——如果是人为直接登录数据库误删，这里能查到痕迹。
  • 有没有误执行备份恢复操作？比如把测试环境的空库备份恢复到生产，看起来像是数据被随机删除。

• 并发冲突处理逻辑错误
  如果你的应用开启了乐观并发（比如用Timestamp/RowVersion字段），处理并发冲突时的逻辑可能有问题：

  • 比如冲突发生后，代码逻辑直接删除了冲突实体，而不是重试或提示用户，导致数据被莫名删除。

• 应用服务器或数据库的权限泄露

  • 应用服务器上的配置文件（比如web.config）是否泄露了数据库账号密码？内部人员或攻击者拿到账号后，直接登录数据库执行删除操作。
  • 数据库服务器的防火墙规则是否过于宽松？允许非信任IP访问，导致外部恶意操作。

排查建议：优先查数据库的事务日志，定位到具体的删除操作来源；同时开启EF的操作日志（比如在SaveChanges前后记录所有执行的SQL语句），看看应用是否在后台触发了删除逻辑。

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