首先直接给结论：事务日志绝对会影响你的200万条记录导入性能，尤其是当导入操作生成大量日志、日志文件膨胀或IO跟不上的时候，会严重拖慢迁移速度。下面分两部分详细说明：

一、为什么事务日志会影响导入性能？ #

不同的数据库恢复模式下，日志的生成和处理逻辑不同，对性能的影响也不一样：

• 完整恢复模式：所有插入操作都会被完整记录到事务日志，200万条记录会生成海量日志。如果日志文件所在磁盘IO性能差，或者没有及时备份日志导致非活动日志无法被截断，日志文件会持续膨胀，甚至触发自动增长（每次自动增长都会暂停操作，等待文件扩容），直接拖慢导入速度。
• 大容量日志恢复模式：针对批量操作（比如BULK INSERT、SELECT INTO）会使用最小日志记录，能大幅减少日志生成量，提升导入效率，但前提是目标表没有非聚集索引（或者是堆表），且满足其他最小日志条件。
• 简单恢复模式：日志会在检查点触发后自动截断，但如果你的导入是一个单一大事务（比如一次性插入200万条），日志还是会持续增长直到事务提交，期间同样可能占用大量IO资源，影响性能。

二、清理/收缩事务日志的脚本（分恢复模式处理） #

1. 先确认当前数据库的恢复模式 #

SELECT name, recovery_model_desc 
FROM sys.databases 
WHERE name = '你的目标数据库名'; -- 替换成SERVER2上TABLEB所在的数据库名

2. 简单恢复模式下的操作 #

简单模式下，日志会自动截断，但可以手动触发检查点加速截断，再收缩日志：

-- 第一步：触发检查点，标记非活动日志为可重用
USE 你的目标数据库名;
CHECKPOINT;

-- 第二步：查看当前日志文件信息（获取日志文件名和当前大小）
USE 你的目标数据库名;
SELECT name AS 日志文件名, size/128.0 AS 当前大小MB 
FROM sys.database_files 
WHERE type_desc = 'LOG';

-- 第三步：收缩日志文件到指定大小（比如收缩到100MB）
USE 你的目标数据库名;
DBCC SHRINKFILE (N'你的日志文件名', 100); -- 替换成实际的日志文件名和目标大小

3. 完整/大容量日志恢复模式下的操作 #

完整模式下，只有备份事务日志后，非活动日志才能被截断，所以先备份再收缩：

-- 第一步：备份事务日志（替换备份路径和文件名）
BACKUP LOG 你的目标数据库名 
TO DISK = 'D:\SQLBackups\YourDB_LogBackup_20240520.bak' 
WITH INIT; -- INIT表示覆盖现有备份文件，如需追加用NOINIT

-- 第二步：查看日志文件信息
USE 你的目标数据库名;
SELECT name AS 日志文件名, size/128.0 AS 当前大小MB 
FROM sys.database_files 
WHERE type_desc = 'LOG';

-- 第三步：收缩日志文件
USE 你的目标数据库名;
DBCC SHRINKFILE (N'你的日志文件名', 100);

临时优化方案：切换到大容量日志模式减少日志生成 #

如果你只是临时做这次数据迁移，可以临时切换到大容量日志模式，大幅减少日志量，提升导入速度：

-- 切换到大容量日志模式
ALTER DATABASE 你的目标数据库名 SET RECOVERY BULK_LOGGED;

-- 执行你的数据导入操作（比如BULK INSERT、SSIS批量加载等）

-- 导入完成后切回原来的恢复模式（比如完整模式）
ALTER DATABASE 你的目标数据库名 SET RECOVERY FULL;

-- 切回后立即做一次完整备份，确保恢复链完整
BACKUP DATABASE 你的目标数据库名 
TO DISK = 'D:\SQLBackups\YourDB_FullBackup_AfterMigration.bak' 
WITH INIT;

三、额外提升导入性能的建议 #

除了日志处理，这些操作也能帮你加快迁移速度：

• 禁用目标表的触发器和非主键约束：导入过程中触发器和约束检查会消耗大量资源，导入完成后再启用

-- 禁用触发器
DISABLE TRIGGER ALL ON TABLE_B;

-- 禁用非主键约束
ALTER TABLE TABLE_B NOCHECK CONSTRAINT ALL;

-- 导入完成后恢复
ENABLE TRIGGER ALL ON TABLE_B;
ALTER TABLE TABLE_B CHECK CONSTRAINT ALL;

• 使用批量导入工具：比如BULK INSERT、OPENROWSET(BULK...)或者SSIS的批量加载，比逐条INSERT效率高N倍，且能触发最小日志记录
• 临时删除聚集索引：如果TABLE_B有聚集索引，导入前删除，导入后再重建，聚集索引的维护会增加大量日志和时间
• 分离数据盘和日志盘：确保TABLE_B所在数据库的数据文件和日志文件放在不同的物理磁盘，减少IO竞争

⚠️ 注意：不要频繁收缩事务日志！日志文件碎片化会导致后续操作的IO性能下降，只有在这次大导入导致日志临时膨胀后，才适合收缩到合理大小（比如根据日常操作的日志量设置，不要收缩到太小）。

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