为什么bulk_logged恢复模式下t-log备份大小未出现预期增长甚至下降

首先澄清普遍存在的认知偏差：bulk_logged恢复模式仅会在触发「最小日志记录的大容量操作」时，才会将对应修改的数据区（extent）追加到事务日志备份中，且备份总大小不一定高于full模式下的日志备份，核心原因如下：

1. 测试中执行的插入操作可能未触发最小日志记录 #

bulk_logged模式下的最小日志特性仅对特定操作生效，需要同时满足多个条件：

• 操作类型必须是大容量操作：包括SELECT INTO、BULK INSERT、OPENROWSET(BULK)、大容量插入BCP、索引创建/重建等，普通的INSERT INTO ... VALUES、逐行/批次小批量插入不会触发最小日志，此时bulk_logged模式的日志记录逻辑和full模式完全一致
• 操作对象满足前提：如果插入目标是聚集索引表且表非空，默认不会触发最小日志；堆表插入需要加TABLOCK表锁提示才会触发最小日志
• 数据库没有启用事务复制、变更数据捕获（CDC）等需要解析全量日志的功能
  如果插入操作未满足以上条件，bulk_logged模式不会额外追加数据页到日志备份，大小自然和full模式无差异甚至更小。

2. 最小日志场景下，日志备份总大小完全可能低于full模式 #

很多人忽略了full模式下大容量操作的日志开销：

• full模式下所有数据变更都会生成全量事务日志，插入2GB数据时，除了数据行本身的变更，还会记录索引变更、页拆分等所有操作细节，事务日志总量往往会超过2GB，对应日志备份的大小也会超过实际插入的数据量
• bulk_logged模式下触发最小日志时，事务日志仅记录数据区分配的元数据，不会记录每行的具体变更，此时事务日志本身的大小通常只有几十到几百MB；日志备份时仅追加自上一次日志备份以来，被大容量操作修改的脏数据区，总大小为「元数据日志大小 + 脏数据区总大小」
  如果脏数据区的总大小低于full模式下生成的全量日志大小，最终的日志备份就会比full模式下更小，这是非常普遍的情况。

3. 额外影响因素 #

如果测试环境开启了备份压缩，bulk_logged模式下日志备份包含的连续数据页的压缩率，通常远高于full模式下离散文本日志的压缩率，进一步缩小了最终备份文件的体积。

测试结果参考：

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