Question

我在SQL 2005数据库中有一个全新的表。作为我们的应用程序部署的一部分，我们加载了大约2.6M行的表。完成后，表中的索引都将重建。然后，用户进入系统并查询该表超时。然后我可以重建索引（使用导入后使用的完全相同的脚本），查询速度很快。

我检查了索引重建后表中没有其他主要数据更改。关于还有什么可能导致这种行为的任何想法？

以下是索引重建脚本的示例：

DROP INDEX dbo.My_Table.Index1
DROP INDEX dbo.My_Table.Index2

ALTER INDEX PK_My_Table ON dbo.My_Table REBUILD

CREATE NONCLUSTERED INDEX Index1 ON dbo.My_Table (column_1 ASC)
CREATE NONCLUSTERED INDEX Index2 ON dbo.My_Table (column_2 ASC)

Answer 1

我怀疑只是第一次添加索引不会重建统计信息。加载后尝试在表上执行DBCC DBREINDEX。您可能还想确保您拥有聚集索引。

Answer 2

可能是统计数据，但不是指数

优化器将获取第一个查询的已更改行数/无统计信息。它决定重建/创建统计数据。

但是：可能存在与索引无关的列级统计信息。

第二次重建与统计目的无关，因为列统计信息已经存在，但它会强制执行计划被丢弃并重新评估

编辑：

SQLServerPedia：

...不会触及列统计信息索引重建过程...

Answer 3

可能只需要很长时间才能完成索引。在第一次索引重建后你等了多久？

更新：我觉得它真的是一个周末的事情，这意味着索引在第一次就行不通。在那种情况下，除了到目前为止所说的内容之外，我没有任何建议。

Answer 4

删除之前的索引，即可批量插入数据。这将允许更快地插入数据。在加载数据之前，还要禁用相关表上的任何触发器。

然后，添加索引。这可以避免您当前正在进行的不必要的冗余索引重建。

另外，正如一位用户已经指出的那样，使用DBCC DBREINDEX比使用DBCC DBREINDEX更有意义。重新添加索引。当然，您也可以update statistics。

更新：由于不推荐使用DBCC DBREINDEX（命令，而不是概念），请使用ALTER INDEX和REBUILD选项。

Answer 5

我认为导入过程中的某些内容会导致索引数据分布在许多数据页中。重建它们可以解决这个问题。

Answer 6

我记得在某处读取SQL Server在创建索引时使用当前统计信息。如果统计信息已过期，则可以针对错误的案例优化正在创建的索引，并使结果效果不佳。

在创建索引之前，请尝试更新桌面上的统计信息。

BOL中的UPDATE STATISTICS条目表明可能发生这种情况：

数据库引擎保存有关每个索引中键值分布的统计信息，并使用这些统计信息来确定要在查询处理中使用的索引。用户可以使用CREATE STATISTICS语句在非索引列上创建统计信息。查询优化取决于分发步骤的准确性：


如果索引中的键值发生重大变化，请在该索引上重新运行UPDATE STATISTICS。

如果已添加，更改或删除索引列中的大量数据（即，如果键值的分布已更改），或者已使用TRUNCATE TABLE语句截断该表，然后重新填充，请使用更新统计数据。

由于您已将数百万行导入空表，我会说您已经遇到上述情况之一。

必须在表上重建索引两次

6 个答案: