SQL Server中避免INSERT锁升级需分批控制（每批1000–2000行）、独立事务包裹、禁用混合DML及触发器干扰；BULK INSERT需满足无非聚集索引、TABLOCK提示和BULK_LOGGED/SIMPLE恢复模式。
INSERT 批量写入触发锁升级，不是语句写错了，而是数据库在锁资源、日志和内存之间做的自动权衡——它发现你一次要锁太多行（比如超 5000 行），就干脆把成千上万个行锁合并成一个表锁，结果本想提速，反而卡死其他查询。
SQL Server 中如何避免 INSERT 触发锁升级
SQL Server 默认在单事务内锁超 5000 行或锁内存超阈值时强制升级为 TAB 级锁。这不是错误，是引擎的“省事策略”，但业务上不可接受。
- 必须分批控制：每批严格限制在
1000–2000行，比 5000 更保守，留出缓冲空间（索引数量、数据宽度、tempdb压力都会影响实际阈值） - 每批用独立事务包裹：
BEGIN TRAN→INSERT（含多值）→COMMIT TRAN，不能依赖隐式提交 - 避免混合 DML：同一批里别混
INSERT和UPDATE，否则锁计数翻倍，更容易提前升级 - 如果表有触发器，更要警惕：触发器内隐式延长主事务生命周期，等于把多个表的锁都绑在同一事务里
BULK INSERT 或 SqlBulkCopy 是更优路径，但必须三要素同时满足：
- 目标表无活跃非聚集索引（
DROP INDEX或先DISABLE） - 显式加
WITH (TABLOCK)提示（漏掉就退化为普通插入） - 数据库恢复模式为
BULK_LOGGED或SIMPLE（FULL模式下不生效）
MySQL 中为什么 INSERT ... VALUES (),(),... 还会锁表
InnoDB 对每条记录仍会申请行锁或间隙锁；十万行拼成一条语句，不是“不锁”，而是“锁得又多又久”。更危险的是：单语句过长可能触发 max_allowed_packet 限制，直接报错 Packets larger than max_allowed_packet are not allowed。
- 每批建议
1000–5000行，具体看单行大小；超过 5000 后 SQL 解析、binlog 写入开销明显上升 - 必须显式控制事务：
SET autocommit = 0，再BEGIN→ 批量INSERT→COMMIT；ORM 默认autocommit=1时，BEGIN可能被后续SELECT意外中断 - 若源数据来自
SELECT（如INSERT INTO t2 SELECT * FROM t1 WHERE ...），默认在REPEATABLE READ下会对源表加 shared next-key lock，阻塞其他写入；可降为READ COMMITTED，但需确认binlog_format = ROW，否则报错 - 别用
OFFSET分页；优先按主键或带索引的时间戳字段切分，例如WHERE id > 100000 AND id
怎么确认是不是锁升级导致阻塞
别猜。SQL Server 可用扩展事件抓实时证据，重点观察 lock_upgrade 事件；MySQL 则要看 SHOW ENGINE INNODB STATUS\G 输出里的 TRANSACTIONS 和 SEMAPHORES 部分，以及 information_schema.INNODB_TRX 中事务持续时间是否异常长。
- SQL Server 中若看到
wait_type = LCK_M_X且resource_description显示TAB（而非KEY或PAG），基本就是锁升级了 - MySQL 中若
trx_state = RUNNING但trx_started时间远早于当前，且trx_mysql_thread_id对应的线程在SHOW PROCESSLIST里状态为update或Locked，大概率是长事务持有锁未释放
真正难的不是分批，而是每一批是否真正释放了锁、连接状态是否干净、事务边界有没有被 ORM 或连接池悄悄破坏。
