在SQL Server中，若要禁用触发器，必须明确指定schema.table和trigger_name这三段式名称。比如，若漏写schema（像Sales），就会默认匹配dbo，从而引发误操作。另外，执行禁用操作后，必须马上查询sys.triggers.is_disabled=1来确认是否生效。而且要注意，该操作是不可回滚的，也不会记录事务日志。

SQL Server 中禁用触发器必须显式指定三段式名称

直接写 DISABLE TRIGGER trg_log ON Orders 在多 schema 环境下极可能误操作——它默认找 dbo.Orders，而你要禁的是 Sales.Orders。命令成功不等于生效，漏掉 schema 就可能关错表的触发器。

正确写法必须带 schema：DISABLE TRIGGER Sales.trg_update_stock ON Sales.Inventory。如果触发器名或表名含空格、连字符等特殊字符，还得加方括号：DISABLE TRIGGER [trg order audit] ON [order header]。

• 执行后立刻查状态：SELECT name, is_disabled FROM sys.triggers WHERE parent_id = OBJECT_ID('Sales.Inventory')，is_disabled = 1 才算真正禁用
• 禁用操作不可回滚、不记事务日志，不能靠 ROLLBACK 撤销
• 视图上的 INSTEAD OF 触发器也适用同样语法，但要注意 ORM 可能绕过视图直写基表，禁用视图触发器无效

MySQL 没有 DISABLE TRIGGER，只能删+重建

MySQL 8.0.23+ 虽支持 ALTER TABLE table_name DISABLE TRIGGER trigger_name，但该语句只在当前会话有效，且不被所有客户端一致支持；低版本压根不认。生产环境别依赖它。

真正可靠的做法是：导出定义 → 删除 → 导入数据 → 重建。顺序不能乱，且每步都要验证。

• 导出前先确认：SHOW CREATE TRIGGER trigger_name，保存结果（注意 DEFINER 用户是否存在）
• 删除用：DROP TRIGGER IF EXISTS trigger_name
• 导入完成后重建，必须确保 SQL_MODE 与原环境一致（尤其 STRICT_TRANS_TABLES），否则逻辑行为可能偏移
• 别用 SET SQL_LOG_BIN = 0 绕过——它跳过 binlog，主从同步会断，且不影响触发器执行

禁用后修复数据时，必须停写入并加锁

触发器禁用期间，DML 语句照常执行，但所有依赖触发器的副作用（如审计字段更新、关联表同步）全部丢失。这时候做数据修复，若应用还在持续写入，修复脚本和业务写入会互相覆盖，越修越乱。

• 修复前务必停写：通知应用侧暂停写入，或临时切走流量；DBA 层面可对目标表加 ALTER TABLE ... LOCK IN SHARE MODE（MySQL）或 WITH (TABLOCKX)（SQL Server）
• 修复语句本身要带校验：比如修复缺失的 updated_at 字段，先 SELECT COUNT(*) FROM t WHERE updated_at IS NULL AND status = 'active'，再 UPDATE t SET updated_at = NOW() WHERE ...
• 修复完不要急着启用触发器——先插入一条测试数据，查日志表或审计字段是否更新，确认逻辑仍适配当前字段类型和约束

PostgreSQL 导入时禁用需绑定事务会话

在PostgreSQL中，执行 ALTER TABLE table_name DISABLE TRIGGER trigger_name 命令时，默认情况下仅对当前会话产生影响。然而，这有一个重要前提，即该命令必须与后续的 COPY 或 INSERT 操作处于同一个事务当中。在默认的自动提交模式下，一旦禁用命令执行完毕，事务就会结束，那么在导入数据时，触发器将会照常运行。

• 必须显式用 BEGIN 开启事务：BEGIN; ALTER TABLE orders DISABLE TRIGGER trg_audit; COPY orders FROM '/tmp/data.csv'; COMMIT;
• 触发器名大小写敏感，查真实名称用：d+ orders 或 SELECT tgname FROM pg_trigger WHERE tgrelid = 'orders'::regclass
• 禁用后记得 ENABLE TRIGGER，否则后续业务写入将永久丢失逻辑；别指望“重启连接自动恢复”

真正麻烦的从来不是“怎么禁”，而是禁用期间的数据状态没人盯——修复脚本跑完，没人验证 audit_log 表是否真收到了那条测试记录，也没人确认 stock_count 是否和修复后的订单量对得上。这些细节漏掉一个，就等于把数据一致性风险从触发器转移到了人工操作上。