在插入大塊數據後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使用統計信息（它是通過運行先前查詢創建的）來優化其執行計劃。我不知道任何細節，但是還要「重新索引所有索引」，檢查兩個測試用例中查詢的執行計劃，以確保計劃是相同的（和/或檢查相關的統計數據）。