sql - 在批量插入期间删除/重建索引

Question

我有一些表，里面有超过 7000 万条记录；我刚刚发现开发人员在批量插入之前删除索引，然后在批量插入结束后再次创建。存储过程的执行时间将近 30 分钟(删除索引，批量插入，然后从头开始重新创建索引

建议:从拥有超过 70 万条记录且每天增加 3-4 百万条记录的表中删除索引是否是一种好做法。

在批量插入之前不删除索引是否有助于提高性能？

在 BIG TABLE 中执行 BULK 插入时应遵循的最佳实践是什么。

感谢和问候

Answer 1

就像 SQL Server 中的所有内容一样，“视情况而定”

插入期间维护索引有开销，插入后重建索引也有开销。明确确定哪种方法产生的开销更少的唯一方法是同时尝试这两种方法并对其进行基准测试。

如果我是一个赌徒，我会打赌保留索引会排除全面重建的可能性，但我没有全貌来做出有根据的猜测。同样，唯一确定的方法是尝试这两种选择。

一个关键优化是确保您的批量插入按聚集键顺序排列。

---

如果我没看错你的问题，那么在加载期间，该表几乎不受限制(锁定)，这是一个问题。

如果您的主要目标是提高可用性/减少阻塞，请尝试采用 A/B 表方法。

A/B 方法分解如下:

给定一个名为“MyTable”的表，您实际上有两个物理表(MyTable_A 和 MyTable_B)和一个 View (MyTable)。

如果 MyTable_A 包含当前“事件”数据集，则您的 View (MyTable) 正在选择 MyTable_A 中的所有列。同时，您可以全权委托(delegate) MyTable_B(其中包含 MyTable_A 数据的副本和您正在编写的新数据。)一旦 MyTable_B 已加载、编制索引并准备就绪，请更新您的“MyTable” View 以指向 MyTable_B 并截断 MyTable_A .

此方法假定您愿意增加 I/O 和存储成本(在您的情况下会大幅增加)以维持可用性。它还假设您的大表也是相对静态的。如果您确实遵循这种方法，我会推荐第二个 View ，例如指向非事件表的 MyTable_old(即，如果 MyTable_A 是当前演示表并被 MyTable View 引用，MyTable_old 将引用 MyTable_B)您将更新在更新 MyTable View 的同时更新 MyTable_old View 。

---

根据您要插入的数据的性质(以及您的 SQL Server 版本)，您还可以利用分区 ( MSDN blog on this topic. )