我打算把事情簡單化了一點給你,讓你可能需要閱讀高達約我談事在我的答案中。
您必須瞭解的兩個概念。分配的空間與可用空間。一個數據庫的大小可能是2GB,但它只使用1GB,因此它已經分配了2GB和1GB的可用空間。當您縮小數據庫時,它將刪除可用空間,因此可用空間應該大約爲0.不要認爲較小的文件大小會更快。隨着數據庫的增長,它必須再次分配空間。當你收縮文件,然後每隔一段時間增長一次,它就不能以連續的方式分配空間。這會造成文件的碎片,從而降低速度。
對於數據文件(.mdb)文件,這並不是很糟糕,但事務日誌收縮會導致虛擬日誌文件碎片問題,從而降低速度。所以簡而言之,幾乎沒有理由按計劃收縮數據庫。閱讀關於SQL Server中的虛擬日誌文件,有很多關於它的文章。 This是一篇關於收縮日誌文件及其不好的原因的好文章。用它作爲起點。
其他索引隨着時間的推移而變得碎片化。這將主要導致SELECT
查詢的性能不佳,但也會影響其他查詢。因此您需要在數據庫上執行一些索引維護。有關如何對索引進行碎片整理,請參見this answer。
更新:
那麼你重建索引的時間不明確。索引重建會在重建期間鎖定索引。從本質上講,他們在此期間是離線的。在你的情況下,它會很快77000行是SQL服務器沒有。因此,重建索引將消耗服務器資源。 IF你有企業版,你可以做在線索引重建,它不會鎖定索引,但會消耗更多的空間。
所以你需要做的是找到一個維護窗口。例如,如果您的系統在8:00至17:00之間使用,您可以安排在數小時後重建維護。用SQL服務器代理進行安排。鏈接中的腳本可以自動運行。
你的數據庫不大。如果IO分成多個磁盤,我已經看到SQL服務器處理750GB的表,而不會承受壓力。任何數據庫服務器中最慢的部分不是CPU或RAM,而是磁盤的IO路徑。儘管這是一個巨大的話題。回到您的觀點,您正在將數據存儲在NVARCHAR(MAX)
字段中。我認爲這是大文本。因此,縮小數據庫後,您會看到大小爲1,62GB的數據,這意味着數據庫中的每行大小約爲1,62,77,000大或大約22Kb。這似乎是合理的。將表格導出到一個文本文件,並檢查你會驚訝的大小,它可能會大於1,62GB。
隨意問如果需要更多的細節。
刪除列:如果要在刪除變量列(ALTER TABLE ... DROP COLUMN)後回收空間,可以使用DBCC CLEANTABLE:「從表格或索引視圖中刪除的可變長度列中回收空間。 ([ref](http://technet.microsoft.com/en-us/library/ms174418.aspx)) –
Ok vijay kumar但是收縮和索引呢? –
Shirnk數據文件 - >碎片 - >對性能不利 –