执行DBCC SHRINKDATABASE后数据库文件变大，求排查操作问题

你之前的操作确实存在问题，导致数据库文件（大概率是事务日志文件）异常膨胀，最终触发硬盘满报错： #

1. 恢复模式未调整：SQL Server默认采用完整恢复模式，执行DBCC SHRINKDATABASE时会产生大量事务日志，而完整模式下日志不会自动截断（除非手动做日志备份），这是日志文件急剧增长、你看到“数据库变大”的核心原因。
2. 目标剩余空间过小：指定1%的剩余空间会迫使SQL Server频繁移动数据页，进一步加剧日志生成量，同时大幅增加操作的耗时和资源占用。
3. 使用SHRINKDATABASE缺乏可控性：该命令会同时处理数据和日志文件，容易引发不可预期的空间占用问题。

修正后的操作步骤（开发环境适用）： #

1. 终止当前未完成的收缩命令

在SSMS的「活动监视器」中找到对应的DBCC SHRINKDATABASE进程，右键选择「终止进程」。

2. 切换数据库恢复模式为简单（避免日志无限制增长）

ALTER DATABASE <DB> SET RECOVERY SIMPLE;
GO

3. 手动触发日志截断

CHECKPOINT;
GO

4. 查看数据库文件详情（确定要收缩的目标文件）

SELECT 
    name AS 文件名,
    file_id AS 文件ID,
    type_desc AS 文件类型,
    ROUND(size/128.0, 2) AS 当前大小MB,
    ROUND((size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0), 2) AS 空闲空间MB
FROM <DB>.sys.database_files;
GO

5. 用DBCC SHRINKFILE分别收缩数据文件和日志文件（更精准可控）

• 收缩数据文件（文件类型为ROWS）：

  -- 方式1：指定收缩后的目标大小（单位MB），比如收缩到5000MB
  DBCC SHRINKFILE (N'你的数据文件名', 5000);
  GO
  
  -- 方式2：指定剩余空闲空间比例，比如保留10%
  DBCC SHRINKFILE (N'你的数据文件名', 10);
  GO
  

• 收缩日志文件（文件类型为LOG）：

  -- 指定日志文件的目标大小，比如收缩到200MB
  DBCC SHRINKFILE (N'你的日志文件名', 200);
  GO
  

补充说明： #

• 虽然你不在意索引碎片，但收缩前可以先重建一次索引（ALTER INDEX ALL ON <表名> REBUILD;），让数据页更紧凑，能减少收缩操作的工作量和耗时。
• 开发环境后续可以关闭数据库文件的自动增长（或设置合理的增长步长），避免类似空间问题重复发生。

内容的提问来源于stack exchange，提问作者P5_