并发INSERT在SQL Server 2022中更慢，因锁升级、日志争用和闩锁竞争导致吞吐不升反降；需用TABLOCK、BULK INSERT或TVP小批提交优化。

为什么并发INSERT在SQL Server 2022里反而更慢？

并发INSERT不等于吞吐翻倍——默认行为下，多个会话同时向同一张表插入数据，大概率触发锁升级、日志争用和闩锁（latch）竞争，尤其当目标表有聚集索引且数据非顺序写入时。常见现象包括：wait_type = LCK_M_X、PAGEIOLATCH_SH飙升、sys.dm_os_waiting_tasks中大量WRITELOG等待。

根本原因不是CPU或磁盘不够，而是事务日志写入路径串行化 + 索引页分裂 + 缓冲区管理器争用。SQL Server 2022没改这个底层模型，所以“开10个线程INSERT”常比单线程还慢。

• 别盲目增加并发数：实测表明，对普通OLTP表，2–4路并发常是拐点；超过后吞吐不升反降
• 确保所有并发INSERT都显式使用TABLOCK（仅适用于BULK INSERT或INSERT INTO ... SELECT），否则各行锁叠加成表锁
• 避免在高并发INSERT期间执行ALTER INDEX ... REORGANIZE或统计信息自动更新，它们会抢KEY或PAGE latch

BULK INSERT并发必须配齐三个最小化日志条件

BULK INSERT是唯一能真正提升并发写入吞吐的原生命令，但它不是“加个WITH就快”，漏掉任一条件就会退化为逐行完整日志，速度可能比INSERT ... VALUES还差。

• 数据库恢复模式必须是BULK_LOGGED或SIMPLE：ALTER DATABASE yourdb SET RECOVERY BULK_LOGGED，导入完立刻切回FULL并做日志备份，否则后续日志无法截断
• 目标表不能有活跃的非聚集索引（含主键/唯一约束自建的索引）：要么提前DROP，要么DISABLE，导入完成后再REBUILD
• 必须显式指定WITH (TABLOCK)，且执行期间无其他会话对该表做写操作；TABLOCK不在WITH子句里=无效

错误示例：BULK INSERT t FROM 'x.csv' WITH (FIELDTERMINATOR=',') —— 缺TABLOCK，默认走行锁，10万行可能卡住；正确写法：BULK INSERT t FROM 'x.csv' WITH (FIELDTERMINATOR=',', TABLOCK)。

用TVP+小批次提交替代盲目并发

当数据来自应用层（如.NET API）、无法落地为文件时，Table-Valued Parameter（TVP）比多线程拼SQL更可控。它把一批行打包传入存储过程，减少网络往返，但依然走完整日志路径——所以关键在“小批次+及时提交”。

• 单次TVP调用建议≤5000行：超1万行时，.NET序列化开销陡增，且SQL Server解析参数表的内存压力明显上升
• 必须显式分批提交：在循环中每插5000行就COMMIT一次，绝不能把全部百万行包在一个事务里
• 存储过程中禁用SET NOCOUNT OFF（保持默认ON），避免客户端被大量xx rows affected消息阻塞
• 目标表对应字段要有索引：如果TVP数据要JOIN维度表，驱动侧字段（如region_id）没索引，优化器仍会扫全表，吞吐瓶颈立刻转移过去

临时表驱动+边界ID分片比@@ROWCOUNT可靠

用WHILE @@ROWCOUNT > 0做分批INSERT是经典陷阱：最后一批不足设定大小时，@@ROWCOUNT变成实际插入行数（比如123），下一轮SELECT没命中任何行，@@ROWCOUNT变0，循环直接退出，剩余数据丢失。

正确做法是用边界值（如id）切片，配合临时表预存范围：

• 先建带聚簇索引的临时表：CREATE TABLE #batch_ids (id INT PRIMARY KEY)，再INSERT INTO #batch_ids SELECT id FROM source WHERE ... ORDER BY id
• 用MIN(id)和MAX(id)驱动分片：WHERE id BETWEEN @start AND @end，每次取固定数量（如10000）的id
• 确保源表id有索引，否则SELECT MIN/MAX本身就成了性能瓶颈

这种模式下，控制逻辑在应用层或SQL脚本里更清晰，不会因某批数据量波动而意外中断——这是生产环境批量导入最不容易出错的底座设计。