Sql server 2008 收缩数据库、释放物理空间有多安全-Sql Server

在寻找解决磁盘空间问题的方法时，我阅读了几篇文章，发现缩小数据库是一种选择，而其他一些人正在删除错误日志文件和事务日志文件。但是,

我发现第一种选择是有争议的，因为它是为了解放思想 未使用的空间SQL使用丑陋的进程并导致索引 长期影响性能的碎片。意思是 在释放空间后，我们将授权运营商 系统用它做它需要做的事情

---

因此，从可用选项列表中删除shrink选项是否公平？

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

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

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

查询来源

你可以查一下

缩小数据库时会发生什么情况？

当您单击“收缩数据库”按钮（或在 自动收缩，或安排作业执行收缩），您正在询问SQL 服务器从数据库文件中删除未使用的空间 SQL使用的进程很难看，导致索引碎片 从长远来看影响性能。你已经释放了空间 让O/S做它需要做的事情。如果你有一个成长的 数据库（与大多数生产数据库一样），这 这意味着该数据库将再次增长。取决于你的自我成长 设置（另一个帖子的另一个恼怒）此增长将 可能会超出需要，你最终会再次萎缩… 充其量这只是额外的工作（收缩生长/收缩生长）和 由此产生的文件碎片由I/O子系统正常处理。 更糟糕的是，这导致了我提到的索引碎片，文件 碎片化，中断本来应该是连续的 文件，并可能导致与I/O相关的性能问题。真正地 不过，这是在浪费时间并引入索引碎片