禁用触发器比优化更有效，因其行级特性导致50万行导入总耗时从50秒降至2秒内，而优化单次耗时仅减至10秒；MySQL不支持语句级触发器，PostgreSQL/SQL Server需按语法禁用并验证生效。
因为行级触发器在批量导入时会为每一行数据单独执行一次，把原本一次性的物理写操作拆成 N 次逻辑写、日志写和锁等待——禁用不是“建议”，而是防止性能雪崩的必要动作。
为什么禁用比优化更有效
触发器单次耗时从 0.1ms 降到 0.02ms，对 50 万行导入来说，总耗时仍从 50 秒降到 10 秒；而禁用后直接回归到 2 秒以内。瓶颈不在“怎么写”，而在“不该这么调用”。
- MySQL 全系列不支持
FOR EACH STATEMENT，所有触发器默认且唯一是行级 - PostgreSQL 的
FOR EACH ROW在COPY或INSERT SELECT中必然触发 10 万次 - SQL Server 的
BULK INSERT不走触发器，但换成INSERT INTO ... SELECT就立刻激活——很多人误以为换命令就安全了 - 哪怕空壳触发器（如只写
SELECT 1）也会强制事务串行化，阻塞并发写入
不同数据库禁用触发器的实操命令
语法差异极大，写错等于没操作，且多数不支持事务内执行。
- PostgreSQL（需 superuser）：
ALTER TABLE orders DISABLE TRIGGER ALL;，启用：ALTER TABLE orders ENABLE TRIGGER ALL; - SQL Server：
DISABLE TRIGGER trg_audit ON dbo.orders;，启用：ENABLE TRIGGER trg_audit ON dbo.orders; - MySQL：无原生命令，安全做法是重命名：
RENAME TRIGGER mydb.orders_after_insert TO mydb.orders_after_insert_disabled;，导入完再改回 - Oracle：
ALTER TRIGGER trg_sync DISABLE;
禁用后必须验证是否真生效
很多人执行完就认为完成了，结果导入时触发器仍在跑——原因通常是静默失败或作用域错误。
- SQL Server：查
sys.triggers表的is_disabled字段是否为 1 - PostgreSQL：查
pg_trigger表的tgenabled字段，值应为D（disabled），启用后应为O或A - MySQL：用
SHOW TRIGGERS LIKE 'orders';确认触发器名已变更 - 禁用必须在自动提交关闭状态下执行，否则会话结束即失效（尤其 PostgreSQL 连接池场景）
禁用期间最容易被忽略的风险点
禁用不是暂停，是彻底跳过——所有副作用都不会发生，且不会自动补全。
- 审计日志漏写、统计表未更新、关联字段未填充，这些都不会事后自动追平
- 若导入中途失败，后续重试前必须人工检查并补全缺失逻辑（比如手动 INSERT 到
audit_log） - 某些合规场景下，审计类触发器被明确禁止停用，需提前确认策略
- 禁用
ALL会同时禁用约束触发器（如外键、唯一性检查），它们由系统隐式管理，需额外处理SET CONSTRAINTS
