sql-server-2008 - 缩小数据库以释放物理空间有多安全 - Sql Server

Question

在寻找解决磁盘空间问题的过程中，我浏览了几篇文章，发现收缩数据库是一种选择，而另一些则是删除错误日志文件和事务日志文件。但是，

I found the first option controversial where in order to free up the unused space SQL uses an ugly process and results in Index fragmentation that affects performance in the long run. Meaning that after deallocating the space we are giving authority to the Operating system do what it needs to with it.

那么，从可用选项列表中删除收缩选项是否足够公平？

Answer 1

确实不建议收缩数据库。您可以这样理解它，当您收缩数据库时，它会导致碎片增加，现在为了减少您尝试重建索引的碎片，这最终会导致数据库大小增加。

您可以自己运行查询来测试

SELECT name, (size*8) Size_KB
FROM sys.database_files
GO
-- Check Fragmentations in the database
SELECT avg_fragmentation_in_percent, fragment_count
FROM sys.dm_db_index_physical_stats (DB_ID(), OBJECT_ID('SecondTable'), NULL, NULL, 'LIMITED')
GO
-- Shrink the Database
DBCC SHRINKDATABASE (ShrinkIsBed);
GO
-- Name of the Database and Size
SELECT name, (size*8) Size_KB
FROM sys.database_files
GO
-- Check Fragmentations in the database
SELECT avg_fragmentation_in_percent, fragment_count
FROM sys.dm_db_index_physical_stats (DB_ID(), OBJECT_ID('SecondTable'), NULL, NULL, 'LIMITED')
GO
-- Rebuild Index on FirstTable
ALTER INDEX IX_SecondTable_ID ON SecondTable REORGANIZE
GO
-- Name of the Database and Size
SELECT name, (size*8) Size_KB
FROM sys.database_files
GO
-- Check Fragmentations in the database
SELECT avg_fragmentation_in_percent, fragment_count
FROM sys.dm_db_index_physical_stats (DB_ID(), OBJECT_ID('SecondTable'), NULL, NULL, 'LIMITED')
GO

^{来自 here 的查询源}

可以查看Don’t Touch that Shrink Database Button!

What Happens when you Shrink a Database?

When you click that shrink database button (or leave a DB in autoshrink, or schedule a job to perform shrinks), you are asking SQL Server to remove the unused space from your database’s files.The process SQL uses is ugly and results in Index fragmentation that affects performance in the long run. You’ve deallocated that space and are letting the O/S do what it needs to with it. If you have a growing database (as the majority of production databases tend to be), this means that that database will grow again. Depending on your autogrowth settings (another pet peeve for another post) this growth will probably be more than necessary and you will end up shrinking again… At best this is just extra work (shrink grow/shrink grow) and the resulting file fragmentation is handled alright by your I/O subsystem. At worse this is causing that index fragmentation I mentioned, file fragmentation, interrupting what would have otherwise been contiguous files and potentially causing I/O related performance problems. Really though, you are wasting time and introducing index fragmentation.