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

Question

我遇到了一个有趣的争论，那就是DBA坚持DELETE命令不应该在T-SQL中使用，相反，删除数据的正确方法是将您希望保留的数据移动到temp表，并删除并重新创建原始表。给出的理由是它应该防止索引碎片问题。

有没有人听说过这是一种实践，任何人都可以提出理由，为什么这可能是一个好主意？这是一个相当复杂的结构，我们一般都在讨论从旨在无限期地聚合数据的表中少量选择性删除（图，每次少于1000行）。

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

Answer 1

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

Answer 2

垃圾，除非你删除99％的行。

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

难道你不要索引维护，它会碎片整理......？

Answer 3

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

然后，您可能会在创建新索引时产生开销，可能是在工作日的中间。假设任何类型的负载和一个体面大小的表将会影响你的性能远远超过一些索引碎片。

非常糟糕的主意。

Answer 4

我同意其他人（前三个帖子，至少）。但是，IT是一个由“依赖”组成的宇宙，所以我会扮演一些恶魔的忠告。

有情况 - 极端情况 - 这可能是有道理的。

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

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

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