TABLOCK仅在BULK INSERT、INSERT...SELECT等批量操作中生效，单行INSERT不支持；需配合BULK_LOGGED/SIMPLE恢复模式、禁用触发器与复制、正确文件权限才能实现最小日志。

为什么单条INSERT加TABLOCK没用

TABLOCK 不是给 INSERT INTO ... VALUES () 这种语句设计的。它只在批量操作路径中生效，比如 BULK INSERT、INSERT ... SELECT 或 SqlBulkCopy。如果你在单行或小批量 VALUES 插入里硬加上 WITH (TABLOCK)，SQL Server 会直接报错或静默忽略——因为该提示不被支持。

BULK INSERT 必须配 TABLOCK 才能最小日志

真正起效的场景是 BULK INSERT：它默认对每行加行锁，成千上万行就等于成千上万次锁申请和日志记录。加上 TABLOCK 后，SQL Server 改为申请一个表级批量更新锁（BU），满足“最小日志记录”前提之一：

• 数据库恢复模式需为 BULK_LOGGED 或 SIMPLE（FULL 模式下 TABLOCK 无效）
• 目标表不能启用复制，且不能有启用的触发器（除非显式指定 FIRE_TRIGGERS）
• 文件路径必须对 SQL Server 服务账户可读（不是你本地电脑的 C:\ 路径）

正确写法示例：

BULK INSERT orders FROM 'D:\data\orders.csv' WITH (FIELDTERMINATOR = ',', ROWTERMINATOR = '\n', TABLOCK);

INSERT SELECT 场景下 TABLOCK 的使用边界

当用 INSERT INTO target SELECT ... FROM source 做大批量迁移时，TABLOCK 可以生效，但要注意两点：

• 提示必须加在目标表上：INSERT INTO target WITH (TABLOCK) SELECT ...，加在 source 上无效
• 如果 source 是堆表且无索引，性能提升明显；若 source 是大索引表，瓶颈可能转移到扫描侧，TABLOCK 作用减弱
• 列存储表例外：它不需要 TABLOCK，反而加了会升级为 X 锁，阻断并行加载

容易被忽略的锁与恢复模式联动

TABLOCK 单独存在毫无意义——它只是最小日志的必要条件之一。很多人改了语句却没切恢复模式，结果日志文件照常暴涨。执行前务必确认：

• 查当前模式：SELECT recovery_model_desc FROM sys.databases WHERE name = 'YourDB';
• 临时切换（导入完记得切回）：ALTER DATABASE YourDB SET RECOVERY BULK_LOGGED;
• 导入完成后立即切回：ALTER DATABASE YourDB SET RECOVERY FULL;，否则后续日志备份链会断

真正卡住性能的，往往不是语法写错，而是恢复模式没动、文件权限不对、或者误以为它能加速循环插入——这些地方一漏，TABLOCK 就成了摆设。