Azure SQL批量数据修改操作中如何最小化日志生成？

问题背景 #

在本地SQL Server中，可通过切换恢复模式为simple或bulk logging来减少批量数据修改操作时的日志生成量。针对Azure SQL有以下疑问：

• 是否有类似的日志优化功能？此前相关问题链接已失效，想了解近两年是否新增相关特性。
• 罕见的大规模更新/插入操作产生的大量日志已引发严重性能问题，本人不在意事务日志，出现问题可自行恢复。
• Accelerated database recovery（加速数据库恢复）功能是否能缓解这类性能问题，还是仅适用于快速恢复场景？相关设置语句如下：

ALTER DATABASE [database_name] SET ACCELERATED_DATABASE_RECOVERY = ON;

解答 #

一、Azure SQL的批量操作日志优化方案 #

Azure SQL数据库（单数据库/弹性池）不支持切换到Simple或Bulk-Logged恢复模式，默认始终使用Full恢复模式。不过针对批量操作的日志优化，有以下可用方案：

• 批量操作的最小日志记录：当满足特定条件时，Azure SQL支持批量操作的最小日志记录。比如使用BULK INSERT、INSERT...SELECT（大容量数据集场景）、SELECT INTO等操作，若目标表无索引（或仅含聚集索引、无非聚集索引）、操作在显式事务外执行，会自动启用最小日志记录，大幅降低日志生成量。
• 分区切换技术：针对大规模数据更新/插入，可采用分区切换——将数据加载到临时分区后切换至目标表，这类操作几乎不产生事务日志，性能损耗极低。

二、加速数据库恢复（ADR）的作用 #

ADR并非直接减少批量操作的日志生成量，核心价值聚焦于快速恢复数据库及降低长事务的阻塞影响：

• 当批量操作失败或需回滚时，ADR通过持久化版本存储（PVS）和逻辑回滚机制，避免传统的全事务回滚，大幅缩短恢复时长。
• 对于批量操作的性能提升，ADR无直接的日志缩减作用，但能避免长事务导致的后续操作阻塞，间接改善整体性能。
• 启用ADR的语句确实为：

ALTER DATABASE [database_name] SET ACCELERATED_DATABASE_RECOVERY = ON;

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