如果您尝试在单个语句中删除大量行,那么很可能是因为等待日志活动。所以您可以: 确保你的日志大小足够,以免增长事件拖慢速度。默认情况下,你的日志可能从1MB开始,增长率为10%。增长事件是昂贵的,如果你删除了10GB的数据,不仅会影响当前性能,还会对未来产生影响(由于对虚拟日志文件的影响)。 如果你要删除整个表,请使用TRUNCATE或DROP/CREATE。 如果你要删除大部分表中的数据,请使用SELECT INTO将要保留的数据放入另一个表中,然后使用TRUNCATE,最后将小部分数据移回原表(或者直接删除旧表,重命名新表,并重新应用约束/权限等)。 首先通过分批删除数据来减少日志记录的影响,而不是一次性删除所有数据。请参考this article。你也可以考虑暂时切换到简单恢复模式,这样你只需要使用CHECKPOINT清除日志,而不需要进行日志备份,但你需要确保及时切换回去并进行新的完全备份以重新初始化日志链。
有一些提示,但你使用的是哪个版本?是企业版吗?无论如何: 如果可以的话,将事务日志移到更快的磁盘上。 分析“where”条件。它是否使用索引来识别要删除的记录?如果没有,能否添加一个索引? 在表上是否有任何可以删除的索引?如果有,删除它们。 这个表是否有外键关联?这可能会严重影响删除操作的速度。 如果你使用的是企业版,并且瓶颈是磁盘IO,那么对行级数据进行压缩可能会有所帮助(或者不会,这取决于你的数据)。 你能否对表进行分区?本地索引和删除分区可能会更快。 通过活动监视器调查瓶颈所在。 当处理大型数据库时,没有一个单一有效的答案,需要添加详细信息。
你应该尝试逐块删除它们,可能需要在循环中进行删除,每个删除迭代都是一个独立的事务,然后在每个循环迭代结束时清除日志。 此外,你需要找到要用作删除记录块值的数字。这需要进行彻底的测试,最好先在用户验收测试中测试块值。 关于如何进行操作,建议你参考将大型删除操作分成块。
再添加几点... 尝试检查谓词是否有索引,并查看统计信息。 如果您要删除大量行并且不想使用临时表选项,请选择tablock选项。 查看是否有任何触发器,特别是在删除后的触发器。 要获得更多帮助,请发布您正在使用的查询、表信息以及任何阻塞信息。