这种批量清理关联客户表的场景我在实际工作中处理过好多次，直接用IN子句循环删确实容易碰到性能瓶颈——尤其是当临时表存了大量GUID、关联表数据量又大的时候。下面给你几个经过生产环境验证的优化思路，按落地优先级排序：

1. 用JOIN替代IN子句，减少子查询开销 #

很多人习惯用IN子句，但当临时表数据量上去之后，SQL Server的查询优化器有时候会把IN转换成重复执行的子查询，额外消耗大量资源。换成JOIN写法后，优化器能更好地利用关联表上的CustomerId索引，匹配速度会快很多：

-- 替换IN的JOIN删除写法
DELETE ah
FROM AddressHistory ah
JOIN ##TempCleanseTheseCustomers t ON ah.CustomerId = t.CustomerId;

DELETE a
FROM Address a
JOIN ##TempCleanseTheseCustomers t ON a.CustomerId = t.CustomerId;

2. 分批次删除，避免大事务锁表 #

如果一次性删除几十万甚至上百万条数据，会触发大事务，不仅日志文件会暴涨，还会长时间锁表，影响其他业务操作。分批次删除是高并发环境下的必备优化：

DECLARE @BatchSize INT = 1000; -- 可根据数据库性能调整批次大小
WHILE 1 = 1
BEGIN
    DELETE TOP(@BatchSize) ah
    FROM AddressHistory ah
    JOIN ##TempCleanseTheseCustomers t ON ah.CustomerId = t.CustomerId;

    -- 当删除行数小于批次大小时，说明已经删完了
    IF @@ROWCOUNT < @BatchSize BREAK;
    -- 可选：加个100毫秒的延时，避免CPU占用过高
    WAITFOR DELAY '00:00:00.100';
END

这样每次只删一小部分数据，把大拆成多个小事务，锁的持有时间大幅缩短，对数据库并发的影响会小很多。

3. 给临时表创建索引，加速关联匹配 #

临时表##TempCleanseTheseCustomers如果没有索引，每次关联的时候都会做全表扫描——要是里面存了几万甚至几十万条GUID，这个开销会非常大。给它加个非聚集索引：

CREATE NONCLUSTERED INDEX IX_TempCleanse_CustomerId ON ##TempCleanseTheseCustomers(CustomerId);

这个操作只需要执行一次，却能让所有关联删除的匹配速度提升数倍，性价比极高。只要临时表数据量超过几千条，这个优化就值得做。

4. 临时禁用触发器和约束（谨慎使用） #

如果关联表有删除触发器（比如删除时同步操作日志）或者外键约束，这些都会在删除时额外消耗性能。如果是在维护窗口执行清理，可以临时禁用它们，完成后再恢复：

-- 先禁用AddressHistory的外键约束和触发器
ALTER TABLE AddressHistory NOCHECK CONSTRAINT ALL;
DISABLE TRIGGER ALL ON AddressHistory;

-- 执行删除操作...

-- 恢复约束和触发器
ALTER TABLE AddressHistory CHECK CONSTRAINT ALL;
ENABLE TRIGGER ALL ON AddressHistory;

⚠️ 注意：这个操作必须在没有其他业务写入的情况下执行，否则可能导致数据不一致。一定要在维护窗口操作，并且执行完后要验证约束的完整性。

5. 特殊场景下用TRUNCATE替代DELETE #

如果某个关联表的数据全部属于要删除的客户（比如客户专属的临时日志表），那用TRUNCATE会比DELETE快得多——因为它不记录单行删除日志，直接释放数据页：

-- 仅当AddressHistory中所有数据都属于要清理的客户时使用
TRUNCATE TABLE AddressHistory;

不过TRUNCATE不能带WHERE条件，而且需要更高的权限，所以只适合全表清空的特殊场景。

6. 调整事务隔离级别（按需使用） #

如果删除过程中不需要严格的一致性，可以降低事务隔离级别到READ COMMITTED SNAPSHOT或者SNAPSHOT，避免长时间的锁等待：

SET TRANSACTION ISOLATION LEVEL READ COMMITTED SNAPSHOT;
-- 执行所有删除操作...

这个需要数据库提前开启ALLOW_SNAPSHOT_ISOLATION选项，适合对数据一致性要求不是极端严格的场景。

总结 #

优先落地前三个优化：用JOIN替代IN、给临时表加索引、分批次删除——这三个是通用且效果最明显的手段。如果是在维护窗口执行，可以考虑临时禁用触发器和约束进一步提速。

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