MySQL不支持DISABLE TRIGGER语法，5.7至8.0均报ERROR 1064；可行替代方案有三：会话变量控制（需显式SET）、临时重命名重建（需停写）、关binlog（仅主库ROW格式，有主备不一致风险）。
MySQL根本不支持 DISABLE TRIGGER 语法
执行 DISABLE TRIGGER 或 ALTER TABLE ... DISABLE TRIGGER 会直接报错 ERROR 1064 (42000)，因为 MySQL 从 5.7 到 8.0 均未实现该功能。PostgreSQL 和 SQL Server 支持，但 MySQL 没有。别在迁移脚本里写这个，也别指望它“悄悄生效”。
真正可行的三种临时跳过方式
目标是让触发器逻辑不运行，而不是“禁用”它——MySQL 触发器一旦创建就始终激活。选哪种取决于你的权限、停机窗口和复制架构：
-
加会话级开关变量：在触发器开头插入
IF @skip_trigger IS NOT NULL AND @skip_trigger = TRUE THEN LEAVE trig_label; END IF;，操作前先执行SET @skip_trigger = TRUE;。优点是无需改结构、不影响其他连接；缺点是所有调用方都得显式设置变量，漏设就失效。 -
临时重命名 + 重建：用
DROP TRIGGER IF EXISTS old_name;+CREATE TRIGGER new_name_temp ...替换原触发器。必须确保应用停写，否则并发 INSERT 可能触发“找不到触发器”错误（MySQL 8.0+ 默认报错而非静默忽略）。 -
关 binlog 写入（仅主库且 ROW 格式）：执行
SET sql_log_bin = OFF;后再做 DML。某些审计/同步类触发器依赖 binlog 事件，关了就收不到信号——但这不是跳过触发器本身，只是让它“没输入”。风险高，仅限紧急修复且确认无下游依赖时用。
为什么 DROP + 导出重建不是首选
虽然 DROP TRIGGER 看似直接，但它带来三个隐性成本：
- 必须提前用
SHOW CREATE TRIGGER trigger_name导出定义，否则升级后无法还原；导出内容含DEFINER=`user`@`host`，新环境若无该用户会报ERROR 1449，需手动删掉或替换。 - 触发器若引用了存储函数、视图或跨库表，重建后这些依赖必须已存在，否则
CREATE TRIGGER静默失败或报ERROR 1305。 - DDL 操作会持有元数据锁（MDL），在大表或高并发下可能阻塞业务语句，超时引发连锁等待。
最容易被忽略的点：嵌套调用和复制一致性
即使你“成功跳过”了表级触发器，仍可能失败：
- 触发器里调用了存储过程，而该过程内部又访问了同一张表——
@skip_trigger对这种嵌套无效，ERROR 1442 依然会出现。 - 在主从架构中，
SET sql_log_bin = OFF不同步到备库，主库跳过触发器，备库却照常执行，导致主备数据不一致。务必确认是否启用了逻辑复制或触发器用于同步场景。 - BEFORE 触发器被跳过，但 AFTER 触发器还在运行；如果两者逻辑耦合（比如 BEFORE 做校验、AFTER 做日志），只动一个会导致状态错乱。
