大规模ETL中临时停用触发器是强制实践，因其行级触发导致100万行插入实际执行100万次逻辑，引发性能骤降、日志暴涨与锁升级；须用数据库原生禁用/启用机制，并在ETL后补执行关键逻辑、修复数据不一致、验证约束完整性。
大规模 ETL 过程中临时停用触发器，不是“建议”，而是多数生产环境的强制实践——因为 INSERT、UPDATE 每行触发一次逻辑，会把线性写入变成指数级开销。
触发器在批量写入时如何拖慢 ETL？
SQL Server、MySQL、PostgreSQL 等主流数据库中，行级触发器（AFTER INSERT / BEFORE UPDATE）默认对每一行生效。ETL 插入 100 万行时，若触发器含日志写入、跨表校验或调用 UDF，实际执行次数是 100 万 ×（触发器内语句数），而非 1 次。
常见现象包括：
-
INSERT INTO sales SELECT ... FROM staging耗时从 2 分钟飙升到 47 分钟 - 事务日志暴涨，填满
tempdb或 WAL 文件 - 阻塞其他并发查询，触发锁升级（如页锁 → 表锁）
停用触发器的正确方式（按数据库区分）
不能直接删掉再重建——会丢失定义、权限和依赖关系。应使用数据库原生的禁用/启用机制：
- SQL Server：
DISABLE TRIGGER trigger_name ON table_name，完成后用ENABLE TRIGGER - PostgreSQL：不支持直接禁用，改用
ALTER TABLE table_name DISABLE TRIGGER ALL（需 superuser 权限） - MySQL：无原生禁用语法，需临时
DROP TRIGGER+ 导出定义 +CREATE TRIGGER回复（慎用） - Oracle：支持
ALTER TRIGGER trigger_name DISABLE
注意：DISABLE TRIGGER ALL 会禁用所有触发器（含系统维护用的），务必确认影响范围；某些审计类触发器可能被合规要求禁止停用。
停用后必须补回的三件事
停用只是绕过实时校验，不代表逻辑可丢弃。ETL 完成后必须显式补足：
- 手动执行触发器中关键逻辑（如更新
inventory.total_qty），用集合操作替代逐行处理 - 检查并修复因跳过触发导致的数据不一致（例如未生成审计日志的记录，需补写
audit_log表） - 验证约束完整性——有些触发器承担了
CHECK或外键替代职责，需额外跑SELECT COUNT(*) FROM table WHERE condition_violated
漏掉任何一项，都可能让下游报表或结算模块产出错误结果，且问题延迟暴露。
真正容易被忽略的，不是“要不要停”，而是“停完怎么收场”。很多团队只记得关，忘了验、忘了补、忘了测——结果上线后发现库存负数、财务凭证断号、审计日志缺失，反而比不开触发器更难排查。
