禁用触发器需按数据库语法精准操作：PostgreSQL用ALTER TABLE ... DISABLE TRIGGER ALL（超级用户），SQL Server用DISABLE TRIGGER name ON table，MySQL无原生命令；禁用后必须显式启用并验证系统表确认状态。
导入大文件时，SQL触发器会逐行执行，拖慢速度甚至失败；直接禁用触发器是最简单有效的绕过方式。
DISABLE TRIGGER 语句怎么写才生效
不同数据库语法差异大，写错就白忙活。重点不是“禁用”，而是“禁用对谁、在哪个作用域”：
- PostgreSQL 不支持
DISABLE TRIGGER，得用ALTER TABLE ... DISABLE TRIGGER ALL（仅限超级用户） - SQL Server 要明确指定触发器名或用
ALL：DISABLE TRIGGER tr_log_insert ON orders - MySQL 5.7+ 没有原生禁用触发器命令，只能临时设
sql_log_bin = 0（仅影响二进制日志，不阻止触发器执行）——这其实没跳过触发器，别踩坑 - 真正通用且安全的做法：在导入前用
SET FOREIGN_KEY_CHECKS = 0（MySQL）或SET CONSTRAINTS ALL DEFERRED（PostgreSQL），但注意这只是关外键/约束，不是触发器
为什么 SET IDENTITY_INSERT ON 不等于跳过触发器
常有人混淆这两件事：SET IDENTITY_INSERT 只解决自增列插入冲突，和触发器完全无关。哪怕开了它，INSERT 还是会触发 FOR EACH ROW 类型的触发器。
- 典型错误现象：导入后发现日志表多出几万条记录，而源数据根本没改——说明触发器仍在运行
- 真实场景：你正在还原生产备份到测试库，但业务触发器会往监控表写状态、调用外部 API、发邮件……这些全得停掉
- 关键区别：
IDENTITY_INSERT是 INSERT 权限开关；触发器是事件响应机制，必须单独控制
禁用后忘了启用，第二天就出问题
这是最常被忽略的一步。禁用是会话级还是对象级？会不会随事务回滚？不同数据库行为不一致：
- SQL Server 的
DISABLE TRIGGER是持久化的，必须显式ENABLE TRIGGER，否则一直失效 - PostgreSQL 的
DISABLE TRIGGER ALL在会话结束时自动恢复，但如果你用的是连接池，可能复用旧会话，导致误判 - 强烈建议把启用语句和导入命令写在同一脚本里，用分号隔开，例如：
DISABLE TRIGGER tr_audit ON users; COPY users FROM '/data.csv'; ENABLE TRIGGER tr_audit ON users; - 如果导入中途失败，启用语句没执行，后续所有
INSERT都不会触发审计——线上环境可能因此漏监控
触发器是否启用，不能靠“应该没问题”来判断，一定要在导入后立刻查系统表确认，比如 SQL Server 看 sys.triggers 表的 is_disabled 字段，PostgreSQL 查 pg_trigger 的 tgenabled 值。
