禁用触发器是防止性能雪崩和级联失败的必要动作，因for each row触发器在万级批量导入时会执行万次，哪怕仅写日志也会拖慢十倍以上；须按数据库语法精准禁用并验证生效。
大批量导入时禁用触发器不是“可选优化”，而是防止性能雪崩和级联失败的必要动作——因为触发器在每行 INSERT/UPDATE/DELETE 时都执行一次，万级数据 = 万次重复逻辑，哪怕只是写一条日志，也可能拖慢导入十倍以上。
触发器在批量导入中为什么成性能瓶颈
触发器本身不慢，但它的执行频次会指数级放大开销。比如一个 AFTER INSERT 触发器里含 INSERT INTO audit_log 和 UPDATE inventory SET qty = qty - NEW.qty，导入 5 万行订单，就会：
- 执行 5 万次 audit_log 插入（可能引发日志表锁争）
- 对 inventory 表做 5 万次单行更新（若没索引，每次都是全表扫描）
- 若触发器里调用存储过程或跨库查询，延迟直接不可控
MySQL/PostgreSQL 默认按行触发；SQL Server 的 BULK INSERT 虽不走触发器路径，但换成 INSERT SELECT 后就立刻激活——很多人误以为“换命令就安全了”，其实只是换了个触发时机。
不同数据库禁用触发器的实操命令
不能统一套用，语法差异大，写错等于白操作：
-
SQL Server：支持精准控制，推荐用具体触发器名
DISABLE TRIGGER [trg_audit_insert] ON [dbo].[orders];启用时：ENABLE TRIGGER [trg_audit_insert] ON [dbo].[orders];注意：DISABLE TRIGGER ALL ON orders会禁用整张表所有触发器，风险更高 -
PostgreSQL（12+）：会话级禁用，需同事务
BEGIN; ALTER TABLE orders DISABLE TRIGGER trg_status_sync; COPY orders FROM '/tmp/data.csv'; COMMIT;老版本不支持DISABLE TRIGGER，只能DROP TRIGGER+CREATE TRIGGER，务必提前pg_dump --schema-only备份定义 -
MySQL：没有原生命令，别信
SET sql_log_bin = 0或sql_mode，它们不跳过触发器 真正有效的是重命名：RENAME TRIGGER `orders_after_insert` TO `orders_after_insert_disabled`;导入完再改回来：RENAME TRIGGER `orders_after_insert_disabled` TO `orders_after_insert`;注意：触发器名必须带数据库前缀，如mydb.orders_after_insert
禁用后必须验证是否真生效
很多人执行完 DISABLE TRIGGER 就以为万事大吉，结果导入时触发器还在跑——原因通常是：
- 在自动提交模式下执行，禁用动作瞬间失效
- 表名或触发器名拼写错误，命令静默成功但没作用到目标对象
- SQL Server 中没切换到正确数据库上下文，USE target_db 忘写了
验证方式统一且可靠：SELECT is_disabled FROM sys.triggers WHERE name = 'trg_audit_insert' AND parent_id = OBJECT_ID('orders');（SQL Server）
SELECT tgname, tgenabled FROM pg_trigger WHERE tgname = 'trg_status_sync';（PostgreSQL，tgenabled = 'D' 表示禁用）
MySQL 则查 information_schema.TRIGGERS 不够直观，重命名后直接 SHOW TRIGGERS LIKE 'orders%' 看名字是否存在更直接
真正难的不是执行那条 DISABLE 命令，而是判断“这个触发器现在能不能禁”——如果它负责生成下游消息、更新实时统计、或被 CDC 工具监听，禁用期间数据流就断了，后续补救成本远高于导入提速收益。操作前必须确认依赖关系，而不是只看执行速度。
