从varbinary列清除冗余数据后回收Azure SQL Server空间的最优方案

直接逐行更新[content]列设为默认值速度慢，核心原因是大字段修改会产生大量IO和日志开销。以下是最快的两种处理方案，按优先级排序：

方案一：新建表迁移数据（推荐，风险更低、速度更快） #

步骤1：创建不含大列的新表 #

复制原表的结构（排除[content]列），同时保留所有主键、约束、索引：

CREATE TABLE dbo.New_FileTrackingTable
(
    -- 按原表结构复制需要保留的列，示例如下
    FileID INT PRIMARY KEY,
    FileName NVARCHAR(255) NOT NULL,
    AzureStoragePath NVARCHAR(500) NOT NULL,
    UploadTime DATETIME2 NOT NULL,
    -- 其他需要保留的业务列...
);

-- 复制原表的非聚集索引（如果有）
CREATE NONCLUSTERED INDEX IX_New_FileTrackingTable_FileName ON dbo.New_FileTrackingTable(FileName);

步骤2：批量迁移数据 #

用INSERT...SELECT批量迁移，比逐行操作高效数倍，若数据量过大可分批次执行：

-- 一次性迁移（适合业务低峰期，日志压力可控时）
INSERT INTO dbo.New_FileTrackingTable
SELECT FileID, FileName, AzureStoragePath, UploadTime /* 其他需保留列 */
FROM dbo.FileTrackingTable;

-- 分批次迁移（避免一次性日志暴涨）
DECLARE @BatchSize INT = 2000;
DECLARE @MaxID INT = (SELECT MAX(FileID) FROM dbo.FileTrackingTable);
DECLARE @CurrentID INT = 1;

WHILE @CurrentID <= @MaxID
BEGIN
    INSERT INTO dbo.New_FileTrackingTable
    SELECT FileID, FileName, AzureStoragePath, UploadTime
    FROM dbo.FileTrackingTable
    WHERE FileID BETWEEN @CurrentID AND @CurrentID + @BatchSize - 1;

    SET @CurrentID += @BatchSize;
END

步骤3：切换原表与新表 #

数据迁移验证无误后，快速替换表名完成切换：

-- 重命名原表为备份表
EXEC sp_rename 'dbo.FileTrackingTable', 'dbo.FileTrackingTable_Old';
-- 重命名新表为原表名
EXEC sp_rename 'dbo.New_FileTrackingTable', 'dbo.FileTrackingTable';

步骤4：快速释放空间 #

直接删除备份表，立即释放大字段占用的空间（比收缩数据库高效得多）：

DROP TABLE dbo.FileTrackingTable_Old;

方案二：直接删除大列（适合快速操作场景） #

Azure SQL Server支持异步删除大列，操作不会长时间阻塞表，但空间释放依赖后台任务进度：

ALTER TABLE dbo.FileTrackingTable DROP COLUMN [content];

该操作执行后，后台会异步清理大列占用的存储页，无需手动触发收缩，但无法实时监控进度。

关键注意事项 #

• 操作前务必全量备份数据库，避免数据丢失。
• 优先选择业务低峰期执行，减少对线上业务的影响。
• 若数据库为完整恢复模式，操作前可临时切换到简单恢复模式以减少日志生成：

ALTER DATABASE YourDatabaseName SET RECOVERY SIMPLE;
-- 执行完迁移/删除操作后切回
ALTER DATABASE YourDatabaseName SET RECOVERY FULL;

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