PostgreSQL导入时临时禁用触发器应使用ALTER TABLE ... DISABLE TRIGGER，需在BEGIN事务内执行，确保与COPY等导入操作同会话；禁用后须及时ENABLE恢复。
PostgreSQL 导入时怎么临时禁用某个触发器
直接禁用，别绕弯。postgresql 提供了 alter table ... disable trigger，它只影响当前会话（如果你用的是 disable trigger all 或具体触发器名），且不会干扰其他连接。关键点是：它必须在同一个事务或会话里执行，且导入命令（如 psql -f 或 copy）得和禁用操作在同一个会话中。
常见错误现象：psql 脚本里先写 ALTER TABLE ... DISABLE TRIGGER，再 \COPY，但没加 BEGIN；结果触发器依然运行——因为默认每条命令自动提交，禁用动作早结束了。
- 用
BEGIN显式开启事务，禁用触发器、执行导入、再COMMIT - 触发器名必须准确，大小写敏感；查它用
\d+ table_name或查pg_trigger - 禁用后记得恢复：
ALTER TABLE ... ENABLE TRIGGER，否则后续业务写入可能漏逻辑
MySQL 中跳过触发器执行的等效做法
MySQL 没有“会话级临时禁用触发器”的语法，SET SQL_LOG_BIN = 0 或 DISABLE KEYS 都不生效。唯一可靠方式是：用 CREATE TRIGGER ... IF NOT EXISTS 的反向思路——在导入前删掉触发器，导入完再重建。
使用场景：批量导入历史数据、ETL 初始化阶段；不能用于生产实时写入流。
- 导出触发器定义用
SHOW CREATE TRIGGER，保存到变量或文件 - 执行
DROP TRIGGER IF EXISTS trigger_name - 做
LOAD DATA INFILE或INSERT ... SELECT - 再执行原触发器
CREATE TRIGGER语句（注意权限：需要TRIGGER权限） - 不推荐用
sql_log_bin = 0：它跳过 binlog，主从同步会断，且不影响触发器执行
SQL Server 导入时绕过触发器的三种实际路径
SQL Server 最常用的是 DISABLE TRIGGER，但它作用域是表级且持久化（除非手动启用），容易被遗忘。更稳妥的是结合会话设置和导入工具行为来控制。
参数差异明显：DISABLE TRIGGER ALL ON table_name 只对当前会话有效，而省略 ALL 指定具体名则全局禁用——后者风险高，多人共用库时慎用。
- 优先用
DISABLE TRIGGER trigger_name ON table_name+ 同一会话中执行BULK INSERT或INSERT ... SELECT - 若用
SqlBulkCopy.NET 类，设置SqlBulkCopy.FireTriggers = false即可，无需改 DDL - 用 SSIS 导入时，在 OLE DB Command 或目标组件里勾选 “Enable triggers” 取消即可，配置即生效
- 注意：
INSTEAD OF触发器无法被FireTriggers = false跳过，必须显式禁用
触发器禁用后容易被忽略的副作用
最常被漏掉的是外键依赖和审计日志断裂。比如一个触发器负责更新 updated_at 字段或写入 audit_log 表，禁用后这些字段就停更了，后续排查时间线会断层。
性能影响反而次要，关键是语义完整性。有些触发器还承担数据清洗职责（如自动补全空字段、标准化枚举值），跳过之后导入的数据可能“合法但异常”。
- 检查触发器是否修改了行本身（
NEW.*赋值）——这类逻辑禁用后，原始数据就缺处理 - 确认下游视图、物化视图或索引是否依赖该触发器维护的状态
- 如果导入量大，禁用触发器虽快，但启用后首次写入可能触发堆积计算（尤其含聚合逻辑的触发器）
真正麻烦的不是怎么关，而是关了之后哪些字段没更新、哪些日志没记、哪些约束没校验——得对着触发器代码一条条对。
