为何Azure上SQL Server 2016中两条UPDATE查询耗时相差8倍？

API 探路者

2026-5-28

为什么两个UPDATE语句耗时差异这么大？

嘿，这个现象确实有点反直觉——同样是更新300万条非索引列，耗时差了8倍，咱们来拆解下可能的原因，再给你一些实用建议：

潜在原因分析

1. 数据页存储与碎片差异

虽然两列都是varchar类型，但实际存储的状态可能天差地别：

如果Category列原本的实际数据长度普遍很短（比如平均10个字符），更新成'KLM'（3个字符）只是覆盖原有字节，行大小没有变化，不需要拆分数据页，SQL Server可以快速批量处理。
而CategoryAlt列如果原本的实际数据长度接近50字符，或者列中有大量NULL值，更新时可能需要调整行的存储空间，甚至触发数据页拆分（如果数据页剩余空间不足）。另外，如果这张表的CategoryAlt所在数据页碎片率极高（比如之前频繁的插入/更新导致页分散），遍历这些碎片页会大幅增加IO开销。

2. NULL值的影响

如果CategoryAlt列原本有大量NULL值，而Category列基本都是非NULL值，两者的更新开销完全不同：

更新非NULL列：只是覆盖原有存储的字节，行结构不变，开销极低。
更新NULL列：需要为行分配新的存储空间来存储'DLM'，这会改变行的大小，甚至导致数据页重新分配，IO和日志开销都会显著增加。

3. Azure SQL的底层资源波动

虽然你说执行期间没有其他数据库活动，但Azure SQL（除非是专用实例）是共享底层资源的。如果执行第二个UPDATE时，刚好遇到Azure底层存储IO、CPU资源被其他租户抢占，或者触发了资源节流，都会导致耗时剧增。

4. 统计信息过时

如果CategoryAlt列的统计信息很久没更新，SQL Server可能无法准确判断数据分布，生成的执行计划效率低下（比如选择了逐行处理而非批量扫描），虽然都是表扫描，但低效的计划也会放大耗时差异。

实用建议

检查数据页状态与碎片：执行以下查询查看表的碎片率和页密度：
```
SELECT 
    index_id,
    index_type_desc,
    avg_fragmentation_in_percent,
    avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(
    DB_ID(), OBJECT_ID('dbo.Datasets'), NULL, NULL, 'DETAILED'
);
```
如果碎片率超过30%，可以执行ALTER INDEX ALL ON dbo.Datasets REBUILD来整理碎片；如果在5%-30%之间，用REORGANIZE即可。

分析列的实际存储情况：用这个查询查看两列的平均长度和NULL数量：

SELECT
    AVG(DATALENGTH(Category)) AS AvgCategoryLength,
    AVG(DATALENGTH(CategoryAlt)) AS AvgCategoryAltLength,
    COUNT(CASE WHEN Category IS NULL THEN 1 END) AS CategoryNullCount,
    COUNT(CASE WHEN CategoryAlt IS NULL THEN 1 END) AS CategoryAltNullCount
FROM dbo.Datasets;

如果CategoryAlt的NULL数量极高，那NULL更新的开销就是主要原因。

更新统计信息：执行UPDATE STATISTICS dbo.Datasets WITH FULLSCAN，确保SQL Server有最新的数据分布信息，生成最优执行计划。

分批更新大表：一次性更新300万条记录会产生大量事务日志，可能导致日志写入瓶颈。尝试分批更新：

DECLARE @BatchSize INT = 10000;
DECLARE @RowUpdated INT = @BatchSize;

WHILE @RowUpdated > 0
BEGIN
    UPDATE TOP (@BatchSize) dbo.Datasets
    SET CategoryAlt = 'DLM'
    WHERE CategoryAlt <> 'DLM' OR CategoryAlt IS NULL;

    SET @RowUpdated = @@ROWCOUNT;
    WAITFOR DELAY '00:00:01'; -- 给日志写入留缓冲时间
END

这种方式可以降低日志压力，避免一次性占用过多IO资源。

监控Azure资源指标：登录Azure门户，查看执行第二个UPDATE期间的CPU使用率、日志写入速率、存储IO延迟等指标，确认是否有资源瓶颈。

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

为何Azure上SQL Server 2016中两条UPDATE查询耗时相差8倍？

潜在原因分析 #

1. 数据页存储与碎片差异 #

2. NULL值的影响 #

3. Azure SQL的底层资源波动 #

4. 统计信息过时 #