Azure SQL DB修改NVARCHAR列长后数据库体积增大原因

这个空间增长和Azure Data Studio无关，客户端工具不会在数据库侧生成未清理的表备份，核心原因是Azure SQL DB（基于SQL Server引擎）的列修改操作逻辑，叠加你的执行方式导致的临时空间占用：

• 首先明确NVARCHAR(MAX)的基础存储规则：当字段存储的内容长度超过8000字节时，数据会被存放到行外的LOB大对象存储页，数据行本身仅保留16字节的指向LOB页的指针；只有长度较短的内容才会直接存在行内数据页。
• 当你执行ALTER COLUMN把NVARCHAR(MAX)类型改为长度限定的NVARCHAR(500)时，哪怕列内所有现有数据的长度都远小于500，SQL引擎也不会仅修改表元数据完成操作，而是会触发全表数据重写：引擎会为表分配全新的数据页集合，把旧表的所有数据逐行拷贝到新页中，在整个列修改操作完成前，旧的数据页不会被标记为可释放。
• 你是逐列单独执行ALTER语句，而非在单条语句中完成所有列的类型修改：每修改1列，引擎就会执行一次全表拷贝、生成一套新的数据页，9个列逐次修改相当于把70万行的表完整重复复制了8次，这些操作过程中生成的旧版本数据页会暂时留在数据文件中，不会在操作结束后立刻被物理删除。
• 你看到的数据库体积上涨包含大量可复用的空闲页：Azure SQL DB默认不会在DDL操作结束后自动收缩数据文件释放空间，这些被标记为“可复用”的空闲页会优先用于后续的新增、修改数据写入，不会持续占用你的存储配额，但在查询数据库已分配空间指标时，会被计入总占用体积。

验证与可选处理方式 #

你可以执行以下SQL查看表的实际有效数据占用和已分配空间的差值，确认空闲页占比：

SELECT 
    OBJECT_NAME(object_id) AS TableName,
    used_page_count * 8 / 1024 AS 实际有效数据占用_MB,
    reserved_page_count * 8 /1024 AS 已分配空间_MB
FROM sys.dm_db_partition_stats
WHERE OBJECT_NAME(object_id) = 'MyTable'

如果需要立刻释放空闲空间（非必要操作，仅在后续无大量数据写入计划时可执行），可以执行数据库收缩命令，但注意收缩操作会产生索引碎片，收缩完成后建议重建表的所有索引。

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