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 是否和修复后的订单量对得上。这些细节漏掉一个，就等于把数据一致性风险从触发器转移到了人工操作上。
