插入大块数据后，Sql Express上的性能下降

Question

我们注意到，与每个记录基础上添加了数据但具有相似数据量的数据库相比，我们的查询在添加了大量数据的数据库（批量插入）上运行速度较慢。 我们使用Sql 2005 Express，我们尝试重新索引所有索引而没有任何更好的结果。 您是否知道数据库中的某种结构问题可能是由于以大块而不是逐个插入数据而引起的？

由于

Answer 1

我看到的一个提示是在进行批量插入之前关闭自动创建统计数据和自动更新统计数据：

ALTER DATABASE databasename SET AUTO_CREATE_STATISTICS OFF WITH NO_WAIT

ALTER DATABASE databasename SET AUTO_UPDATE_STATISTICS OFF WITH NO_WAIT

然后，通过以下两种方法之一手动创建统计数据：

--generate statistics quickly using a sample of data from the table
exec sp_createstats 

或

--generate statistics using a full scan of the table
exec sp_createstats @fullscan = 'fullscan'

完成后，您可能还应该重新启用自动创建和自动更新统计信息。

另一种选择是在批量插入后检查索引并对其进行碎片整理。看看Pinal Dave的blog post。

Answer 2

可能SQL Server在许多小块中分配了新的磁盘空间。在进行大型事务时，最好在数据和日志文件中预先分配大量空间。

Answer 3

这是一个有趣的问题。

我猜想Express和非Express具有相同的存储布局，因此当您使用Google搜索其他有类似问题的人时，请不要将自己限制在谷歌搜索Express版本中的问题。另一方面，批量插入是一种常见的操作，性能很重要，所以我不认为这可能是以前未检测到的错误。

一个显而易见的问题：哪个是聚集索引？聚集索引也是主键吗？插入时主键是否未分配，因此由数据库初始化？如果是这样，那么在数据库分配的连续值的模式或序列中可能存在差异（两种插入方法之间），这会影响数据的聚合方式，从而影响性能。

其他：除了索引之外，人们还说SQL使用统计信息（它是由于运行以前的查询而创建的）来优化其执行计划。我不知道任何细节，但除了“重新索引所有索引”之外，请在两个测试用例中检查查询的执行计划，以确保计划相同（和/或检查相关的统计信息）。 / p>