截断/大插入后是否应该重建索引？

10

我有一个存储过程，它会在插入新数据（基于其他表中的数据，计算等）之前，截断每个表中各有约175万行的某些表。

基本轮廓非常简单：

截断表
在大约75,000的“批次”中插入175万行。

我想知道是否应该在此过程中的任何时候显式重建索引？例如

截断表
ALTER INDEX ALL ON xxx REBUILD WITH (FILLFACTOR=90) [或类似的东西]
插入175万行

也许

ALTER INDEX ALL ON xxx DISABLE
截断表
插入175万行
ALTER INDEX ALL ON xxx REBUILD WITH (FILLFACTOR=90) [或类似的东西]

非常感谢任何帮助...不是DBA-知道DB很好的开发人员会更准确！

sql-server performance index

— BlueChippy
source

有关表结构，当前存在的索引以及正在插入的数据的外观（按特定顺序？是否与聚簇索引对齐？）的更多信息会有所帮助。我也认为在完成此过程之前该表不可用？知道有批量导入的选项是很高兴的。

— Mike Walsh

也许您应该截断其中的表插入，并查看索引碎片是什么，以查看是否需要这样做。

— Zane 2012年

v：2008标准。在从csv，excel，Oracle和其他SQL数据库加载数据之前，源数据是多个临时表。在此阶段，表的结构都相同：6个字符的ID，3个字符的代码，10个十进制的cols（20,5）。主键是ID +代码。数据正在加载，insert into并且现在没有order by子句，但是我可以补充一下是否有帮助？ID和代码也分别编入索引。

— BlueChippy 2012年

6

与大多数此类问题一样，这取决于。您不可能为所有涉及的索引以“正确”的顺序插入数据，这意味着所有这些索引在插入过程中可能会遇到很多页面拆分。因此，假设您要按聚集索引顺序插入。您可以禁用所有非聚集索引，截断，插入，然后重新生成所有非聚集索引。当然，尝试两种方法都可以告诉您真相更快，而不管其背后的理论如何。:)

— 本图尔
source

1

启用所有索引的Plan Basic可能很慢，并且可能导致碎片。

截断的空表上的ALTER INDEX REBUILD无效，因此您需要修改PlanA。它应该是：

截短
插
改建索引

它可能仍然很慢，但是至少您可以获得清晰的索引。

计划B很好。测试所有这三个，看看哪个最快，哪个索引碎片最少。然后确定重建是否值得。

— 奥比林
source