sql server大容量插入最小化日志需同时满足：①数据库恢复模式为simple或bulk_logged；②表为空且显式使用tablock提示；③禁用非聚集索引及约束；④避开镜像环境或改用sqlbulkcopy+checkconstraints选项。
SQL Server 大批量插入时想最小化日志，关键不是“能不能”，而是“满足哪些硬性条件”。不满足就强制走完整日志，哪怕加了 TABLOCK 也没用。
必须先切到大容量日志恢复模式
完整恢复模式下，BULK INSERT、INSERT ... SELECT、SqlBulkCopy 全部按完整方式记日志——这是铁律。最小日志只在两种模式下可能生效：
- 简单恢复模式（
SIMPLE）：日志自动截断，但无法做时间点恢复 - 大容量日志恢复模式（
BULK_LOGGED）：仅对特定操作最小日志，且仍支持日志备份（但备份后需立即做一次完整备份）
执行前务必确认并切换：
ALTER DATABASE [YourDB] SET RECOVERY BULK_LOGGED;
注意：BULK_LOGGED 是临时策略，导入完应尽快切回 FULL 并做一次完整备份，否则后续日志备份会失败。
表状态和锁提示缺一不可
最小日志不是加个 TABLOCK 就自动触发，它严格依赖表的物理结构和当前状态：
- 堆表（无聚集索引）：空表 +
TABLOCK→ 行数据最小日志；非空表 +TABLOCK+ 有非聚集索引 → 行和索引都**不**最小日志 - 聚集表（有聚集索引）：仅当表**完全为空** +
TABLOCK→ 聚集索引页最小日志；只要已有任何数据，就退化为完整日志 -
SqlBulkCopy默认不带TABLOCK，必须显式指定：sqlBulkCopy.SqlBulkCopyOptions = SqlBulkCopyOptions.TableLock;
常见错误：以为加了 TABLOCK 就万事大吉，结果发现日志暴涨——大概率是表非空或有索引干扰。
索引和约束必须提前处理
即使满足恢复模式和表状态，有以下任一存在，最小日志也会失效：
- 启用的非聚集索引（无论是否空表）
- 启用的外键、唯一约束、CHECK 约束
- 启用的触发器
实操建议：
- 导入前禁用所有非聚集索引：
ALTER INDEX [IX_Name] ON [Table] DISABLE; - 禁用约束：
ALTER TABLE [Table] NOCHECK CONSTRAINT ALL; - 导入完成再重建：
ALTER INDEX [IX_Name] ON [Table] REBUILD;、ALTER TABLE [Table] CHECK CONSTRAINT ALL;
注意：DISABLE 索引比 DROP/CREATE 更快，且保留元数据定义；但禁用约束后，必须确保导入数据本身满足业务逻辑，否则后续启用会报错。
避免镜像环境下的 suspend 风险（RDS/2008 R2 特别注意）
SQL Server 2008 R2 及部分 RDS 实例中，大容量操作与数据库镜像共存时，极易触发镜像 suspend 状态——微软明确表示该版本不会修复。
绕过方案只有两个：
- 改用
SqlBulkCopy并启用SqlBulkCopyOptions.CheckConstraints（而非默认的TableLock），牺牲一点性能换取镜像稳定 - 临时停用镜像，导入完成再重新配置（仅限维护窗口允许的场景）
这个坑特别隐蔽：日志没爆、语句没报错，但镜像链路静默中断，主库一切正常，备库已停止同步——直到 failover 时才发现数据丢失。
