performance - 插入大块数据后 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 的博客文章。

Answer 2

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

Answer 3

这是一个有趣的问题。

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

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

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