删除并重新创建表...以避免索引问题？

Question

我正在与DBA发生一个有趣的争论，他坚持认为不应该在T-SQL中使用DELETE命令，而是删除数据的正确方法是将您想要保留的数据移动到临时表，删除并重新创建原始表。为此提供的理由是它应该防止索引碎片问题。

有没有人听说这是一种做法，任何人都可以提出为什么这可能是个好主意？这是一个相当复杂的结构，我们通常会讨论用于无限期聚合数据的表的少量选择性删除（图中，一次少于1000行）。

我无法想象这样做的理由，而不是简单地在适当的时候重新组织/重建索引，但如果我遗失某些东西，我会很乐意接受教育。谢谢！

Answer 1

垃圾，除非您删除了99％的行。

有一些方面，例如事务日志效果，但删除表，键，索引以重新创建更复杂且容易出错。

难道你没有索引那些会碎片整理的维护......？

Answer 2

在这种情况下，我不同意DBA。我不喜欢将我的“好”数据从物理结构中移出到临时表中，然后在重新创建后返回到新创建的结构，只是为了尝试减少索引碎片。解决方案是使用删除语句删除数据，如果碎片成为问题，则在该点重新索引。

Answer 3

您应该至少每周运行一次维护计划来对索引进行碎片整理并更新统计信息，这将使他的论点完全没有实际意义。

然后，您可能需要在工作日中间创建新索引。假设任何类型的负载和一个相当大的表将影响你的性能远远超过一些索引碎片。

非常糟糕的主意。

Answer 4

我同意其他所有人（前三个帖子，至少）。然而，IT是一个由“它依赖”组成的宇宙，所以我会玩一些魔鬼的推荐。

在某些情况下 - 极端情况 - 这可能是有道理的。

• 如果您使用新结构更新数据库并且要求清除旧数据，请确保 - 当然，您必须在维护（停机）窗口期间执行此操作。
• 如果您从大量数据集中删除除了极少数行之外的所有行（这与存储空间有关，而不仅仅是行数） - 但是，如下所示，有更好的选项
• 如果由于事务日志文件膨胀而导致数据太多且硬盘空间太小，则存在耗尽的危险
• 如果您不必担心外键
• 如果您可以在此过程中使数据库脱机。如果不这样做，如果你能确保锁定受影响一分钟或更长时间的一个或多个表不会导致服务的过度中断。 （你真的可以100％确定，在你想做这项工作的时候，没有人和没有[预定]的东西实际上会使用你的数据库吗？）
• 如果“chunkifying”删除（例如DELETE TOP 1000 ...）某种程度上不是一个选项
• 如果TRUNCATE TABLE不是选项
• 如果基于分区的解决方案不是一个选项

然后，也许，它可能有意义。但可能不是。

值得一提的是，我几乎可以看到DBA在其职业生涯早期基于上述某些情况而出现的情况，以及之后在所有类似情况下使用他们的“经验教训”。