使用INSERT WITH (TABLOCK)并行插入SQL Server堆表时出现死锁

核心锁行为差异 #

你的两种插入语法，锁机制的本质区别在于TABLOCK触发的锁类型与资源竞争范围：

1. 你的VALUES批量插入（fast_executemany） #

即使加了WITH (TABLOCK)，SQL Server对这种插入操作的锁处理逻辑是：

• 首先获取表级意向排他锁（IX）：TABLOCK仅指定锁粒度为表，但插入操作默认会使用意向锁，允许其他进程同时持有表级意向锁（比如其他插入进程的IX锁）。
• 插入过程中需要修改PFS页（页分配空间管理页）和IAM页（索引分配映射页）：这两类页是堆表的全局共享资源，所有插入进程都需要访问它们来分配新数据页或标记页空间使用情况。
• 死锁触发点：多个进程会先获取PFS/IAM页的共享锁（S锁），尝试修改时需要升级为排他锁（X锁），此时若进程A持有S锁等待进程B释放S锁，进程B也在等待进程A，就会形成循环等待，触发1205死锁。

2. 微软指南的INSERT...SELECT WITH(TABLOCK) #

这种语法属于大容量加载操作，SQL Server会特殊处理：

• 直接获取表级排他锁（X锁）：TABLOCK在此场景下会触发大容量加载的锁机制，整个表被独占，其他进程无法同时插入，从根源避免了资源竞争。
• 同时启用最小日志记录，进一步提升加载性能，这也是指南推荐该方式的原因之一。

额外优化方向 #

你用多进程并行插入的思路本身存在资源竞争风险，堆表没有聚集索引来分散插入位置，多个进程默认都会往堆表的最后数据页（或新分配页）插入，加剧了PFS/IAM页的锁竞争。如果要保留多进程方案，可尝试：

• 给堆表添加分区，让每个进程插入到独立分区，隔离资源竞争。
• 调整批量插入的大小，减少单次插入对共享页的访问频率。

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