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

Question

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

谢谢

Answer 1

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

Answer 2

一个提示，我所看到的是做批量插入之前关闭自动创建统计和自动更新统计：通过2种方法之一

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 3

这是一个有趣的问题。

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

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

还有其他的东西：和索引一样，人们说SQL使用统计信息（它是通过运行先前查询创建的）来优化其执行计划。我不知道任何细节，但是还要“重新索引所有索引”，检查两个测试用例中查询的执行计划，以确保计划是相同的（和/或检查相关的统计数据）。