禁用约束前必须确认三件事：确保无活跃事务阻塞操作、导入数据已清洗干净、记录所有被禁用约束名以便恢复。
禁用约束前必须确认的三件事
SQL Server 的 CHECK 和 FOREIGN KEY 约束在批量导入时会逐行校验，严重拖慢速度。但直接禁用有风险：如果数据本身不满足约束条件，启用后会报错甚至导致约束被标记为“未信任”，后续查询优化器可能跳过该约束做执行计划优化。
- 确认目标表当前没有活跃事务或正在被其他进程读写，否则
ALTER TABLE ... NOCHECK CONSTRAINT可能被阻塞 - 确保导入数据已清洗干净——禁用约束不等于跳过校验，只是推迟到启用时集中验证
- 记录下所有被禁用的约束名，避免遗漏恢复，可用
SELECT name FROM sys.foreign_keys WHERE parent_object_id = OBJECT_ID('YourTable') AND is_disabled = 1后续核对
禁用与启用约束的标准写法（含事务包裹）
不要只执行禁用，必须搭配事务和错误处理。否则导入中途失败，约束处于禁用状态却没人发现，后续业务就可能写入脏数据。
BEGIN TRY
BEGIN TRANSACTION;
<pre class="brush:php;toolbar:false;">-- 禁用所有 CHECK 和 FOREIGN KEY 约束
ALTER TABLE dbo.Users NOCHECK CONSTRAINT ALL;
-- 执行批量导入（例如 BULK INSERT 或 SqlBulkCopy）
BULK INSERT dbo.Users FROM 'D:\data\users.csv'
WITH (FIELDTERMINATOR = ',', ROWTERMINATOR = '\n', FIRSTROW = 2);
-- 启用约束并强制验证现有数据
ALTER TABLE dbo.Users WITH CHECK CHECK CONSTRAINT ALL;
COMMIT TRANSACTION;END TRY BEGIN CATCH ROLLBACK TRANSACTION; THROW; -- 重新抛出错误，让调用方知道失败了 END CATCH
注意：WITH CHECK CHECK CONSTRAINT ALL 中的两个 CHECK 不是笔误——第一个表示“启用后验证历史数据”，第二个才是“启用约束”动作。漏掉第一个，约束虽启用但仍是 NOT TRUSTED 状态。
为什么不用 DISABLE TRIGGER？
有人试图用 DISABLE TRIGGER ALL ON dbo.Users 来提速，这是误区。触发器（尤其是 INSTEAD OF 或 AFTER）确实会影响性能，但批量导入（BULK INSERT、SqlBulkCopy）默认绕过大多数触发器，除非显式指定 FIRE_TRIGGERS。而约束校验无法绕过，这才是真正的瓶颈。
-
BULK INSERT默认不触发AFTER触发器；加WITH (FIRE_TRIGGERS)才会触发，此时才需考虑禁用 -
FOREIGN KEY和CHECK约束始终生效，无论是否BULK模式 - 禁用触发器不能替代约束禁用，两者解决的问题不同
导入后约束变成 untrusted 的典型现象
如果启用时用了 WITH NOCHECK CHECK CONSTRAINT（少了一个 CHECK），或者启用语句执行失败回滚了但没重试，约束会处于 is_not_trusted = 1 状态。此时查询计划可能忽略该约束，导致本该走索引查找的变成全表扫描。
检查方法：SELECT name, is_not_trusted FROM sys.foreign_keys WHERE parent_object_id = OBJECT_ID('Users')。值为 1 就得重新执行 ALTER TABLE ... WITH CHECK CHECK CONSTRAINT ...，且必须成功——失败说明数据真有问题，得先修复数据再重试。
真正耗时的不是禁用动作本身，而是启用时的全量校验。所以务必在导入前确保数据合规，否则这个“加速”最后会变成“卡死”。
