日志溢出主因是事务日志无法截断，而非INSERT语句本身；关键在于显式提交+匹配恢复模式的日志备份策略；BULK INSERT性能最优但限制多；TVP适合应用层结构化数据推送；分批处理须用边界ID而非@@ROWCOUNT控制循环。
日志溢出根本不是INSERT语句本身的问题
日志爆满的根源在于事务日志无法及时截断，而不是“INSERT太多”。SQL Server 的恢复模式直接决定日志能否自动收缩：简单恢复模式下，每次检查点（CHECKPOINT）后未提交的日志可被覆盖；完整恢复模式下，必须靠日志备份才能释放空间。如果你没做日志备份，哪怕只插1万行，log_full错误照样出现。
别迷信“分批就能防溢出”——如果批次间没提交、或整个循环包在一个显式事务里，日志照涨不误。关键动作只有两个：显式提交 + 匹配恢复模式的维护策略。
BULK INSERT 是最快但限制最多的选择
BULK INSERT 是绕过常规日志记录路径的机制，在满足最小化日志前提下，性能远超普通 INSERT。但它有硬性依赖：
- 目标表必须是空的，或已禁用所有索引（含主键约束），否则无法启用最小化日志
- 必须使用
TABLOCK提示，且不能有其他并发写入者 - 数据源只能是本地文件、UNC路径或 Azure 存储（SQL Server 2022 支持 SAS 和托管标识）
-
FORMAT = 'CSV'要求字段值不含换行符和未转义引号，否则解析失败
示例中容易漏掉的是 ROWS_PER_BATCH：设为 10000 比默认值更利于内存复用，但超过 50000 可能触发 tempdb 压力上升。
表值参数（TVP）适合从应用层推送结构化数据
当你无法把数据落地成文件（比如数据来自 API 或内存集合），Table-Valued Parameter 是最可控的批量方案。它本质是把一批行打包成一个参数传入存储过程，避免逐条网络往返。
注意三点：
- 必须提前创建用户定义表类型：
CREATE TYPE BulkUdt AS TABLE (Id INT, UserName NVARCHAR(32), Pwd VARCHAR(16)) - .NET 中需用
DataTable或SqlDataRecord构造，不能直接传 List - 单次调用建议控制在 10000 行以内，否则序列化开销陡增，且可能触发
max degree of parallelism争抢
它仍走完整日志路径，所以务必配合小批次提交（比如每 5000 行 COMMIT 一次），不能指望 TVP 自动帮你省日志。
用临时表+WHILE循环分片时，@@ROWCOUNT 是陷阱
常见写法是 WHILE @@ROWCOUNT > 0 驱动循环，但这在最后一批不足 @BatchSize 时会提前退出——因为上一轮 INSERT 实际只插了 123 行，@@ROWCOUNT 就是 123，下一轮 SELECT 没命中任何行，@@ROWCOUNT 变 0，循环终止，剩余数据丢失。
正确做法是用边界 ID 控制：
DECLARE @MinID BIGINT = 0, @MaxID BIGINT; SELECT @MaxID = MAX(id) FROM #staging; WHILE @MinID < @MaxID BEGIN INSERT INTO dbo.target_table (col1, col2, col3) SELECT col1, col2, col3 FROM #staging WHERE id > @MinID AND id <= @MinID + @BatchSize; <p>SET @MinID = @MinID + @BatchSize; COMMIT; -- 关键：显式提交 END</p>
真正容易被忽略的，是 COMMIT 的位置——它必须在每次 INSERT 后立即执行，不能挪到循环外；也不能依赖隐式事务，因为默认是 AUTOCOMMIT 模式，而你的代码很可能关掉了它。
