bulk_logged恢复模式不等于“最小日志”，它仅对特定大容量操作（如bulk insert、select into、带tablock的insert...select）放宽日志要求；普通insert仍完整日志。
SQL Server 中 BULK_LOGGED 恢复模式是否等于“最小日志”？
不是。启用 BULK_LOGGED 模式本身不会让普通 INSERT 语句自动最小日志——它只对特定大容量操作（如 BULK INSERT、INSERT ... SELECT 从外部源、SELECT INTO）放宽日志记录要求。普通循环插入或单条 INSERT 仍走完整日志。关键在于操作类型，而非数据库恢复模式本身。
哪些操作真正支持最小日志记录？
必须同时满足以下条件才可能触发最小日志：
- 数据库处于
BULK_LOGGED或SIMPLE恢复模式（FULL模式下默认不启用） - 目标表无非聚集索引，或有非聚集索引但满足“排序+无并发修改”前提
- 使用明确的大容量操作语法：
BULK INSERT、INSERT INTO ... WITH (TABLOCK) SELECT ...、SELECT INTO - 表未被复制（replication）、变更数据捕获（CDC）或变更跟踪（CT）启用
最常用且可控的是带 TABLOCK 提示的 INSERT ... SELECT：
INSERT INTO target_table WITH (TABLOCK) SELECT * FROM staging_table;
TABLOCK 提示为什么是关键开关？
没有 TABLOCK，即使在 BULK_LOGGED 模式下，SQL Server 也会对每页加锁并逐行记录日志，失去最小日志效果。加上后，SQL Server 将整张表视为一个单元，仅记录区（extent）分配操作，跳过单行日志开销。
注意：
-
TABLOCK是表级排他锁，会阻塞其他写入，需评估业务并发影响 - 若目标表有非聚集索引，SQL Server 可能退回到完全日志（除非数据已按索引键排序且使用
ORDER BY+TABLOCK） - 最小日志不适用于带有计算列、触发器、外键约束或启用 CDC 的表
如何验证是否真的走了最小日志？
直接查事务日志无法直观判断，更可靠的方式是监控日志空间增长和操作耗时对比：
- 执行前运行
DBCC SQLPERF(LOGSPACE)记录日志使用率 - 执行插入后立即再查，对比增量；最小日志下增长应远小于常规插入
- 用
sys.dm_db_session_space_usage查当前会话的user_objects_alloc_page_count，突增但user_objects_dealloc_page_count接近零，说明大量新页分配而非行更新
别依赖“快就等于最小日志”——某些场景下索引碎片或内存压力掩盖了日志瓶颈，实际日志量可能并没减少。
最小日志不是万能加速器，它绕过了日志保护机制，意味着在 BULK_LOGGED 模式下做这类操作后，必须立即做日志备份，否则故障恢复时可能丢失这批数据。
