软删除以提高性能:都错了吗？

Question

几年前，我读到软删除会提高删除的性能，因为它不会实际删除项并影响集群(和所有其他)索引，它只会更改一个值。

我最近试过了，我的表现非常令人失望。

所以我在网上搜索软删除的一个很好的实现，最后我读到的第一件事就是文章/博客说“软删除是不好的”。

很明显，当桌子变大的时候，它会带来最大的伤害.

我不认为我所做的会使表变得更大，因为每晚(每天)的维护会删除(实际上)所有被标记为删除的行。

那么，软删除是否真的会影响性能呢？真正的删除是否会导致整个集群表被完全重新排序(这将是很多磁盘操作！)？

Answer 1

在某些情况下，软删除并不意味着永久删除。您可以将删除工作推迟到某个后台作业(例如，在重新组织/重建索引之前)，这样原始事务就不必等待删除发生(特别是当您有级联删除、触发器等时)。

在其他情况下，软删除根本不是性能要求，而是一种避免永久删除数据的方法，因此总是有跟踪的。在这种情况下，您希望软删除是永久的。(但是，如果您在某个时候“删除”了大量数据，表将主要是“删除”数据。如果这是模式，并且永久保留数据是必需的，那么您可能会考虑使用存档表来保存已删除的行，您还可以作为延迟的后台任务执行这些行，但仍然只需要原始事务更新标志。)

在这两种情况下，都可以使用过滤指标来提高运行时性能。无法指导您需要包括哪些列，但您可以这样说：

CREATE INDEX x ON dbo.table(col) INCLUDE(othercol)
WHERE deleted = 0;

这听起来可能有违直觉，但您也可能希望反向索引能够使您的删除操作更快，至少在标识要删除的行方面是这样。在这种情况下，您可能只想要主键：

CREATE INDEX y ON dbo.table(key) WHERE deleted = 1;

请注意，有许多限制：

• 如何过滤索引可以成为一个更强大的特性
• 你可以(和不能)用过滤索引做的事