MySQL原生不支持DISABLE TRIGGER语法，所谓“禁用”实为绕过执行：最稳妥方式是在触发器内加IF @disable_trigger IS NULL THEN...END IF;并用会话变量控制，或重命名触发器名临时规避匹配；DROP+CREATE因非原子性而高危，ALTER TABLE DISABLE TRIGGER纯属误传。
MySQL 原生不支持 DISABLE TRIGGER 语法，所谓“禁用”只能是绕过执行，不是系统级开关。你必须接受：这不是真正的禁用，而是让触发器逻辑不生效。
用会话变量控制触发器逻辑（最常用）
在触发器内部加 IF @disable_trigger IS NULL THEN ... END IF; 包裹主体逻辑，再通过 SET @disable_trigger = 1; 控制是否跳过。这是生产环境最稳妥的软禁用方式。
- 必须先用
SHOW CREATE TRIGGER trigger_name;备份原定义，否则重建时容易漏逻辑或出错 -
@disable_trigger是会话级变量，只对当前连接有效；连接池复用连接时，记得每次操作前显式重置：SET @disable_trigger = NULL; - 重建触发器时务必切换
DELIMITER，否则分号会让语句提前终止 - 不要用
@@global.disable_trigger——MySQL 不允许自定义全局用户变量
重命名触发器绕过匹配（适合批量删数据）
用 RENAME TRIGGER old_name TO new_name_disabled; 让 MySQL 在 DML 时找不到原名触发器，从而跳过执行。删除完成后再重命名回来即可。
- 触发器名必须带数据库前缀，例如
mydb.tbl_after_delete_log，否则报错ERROR 1357 (HY000) - 重命名不影响触发器定义本身，也不影响依赖对象（如函数、其他表）的权限校验
- 比删重建安全：避免两步非原子操作导致中间窗口期漏触发，也避免重建失败后永久丢失
- 不能用于跨库触发器的“临时禁用”，因为
RENAME TRIGGER不支持跨库操作
为什么不能用 DROP + CREATE 模拟开关
看似简单，实则高危。DROP 和 CREATE 是两个独立语句，中间存在不可控窗口期。
- 并发写入下，可能有 INSERT/UPDATE 在 DROP 后、CREATE 前发生，完全绕过触发逻辑
- CREATE 失败（语法错、权限不足、表结构已变）会导致触发器永久消失，且无自动回滚
- 没有事务保障：
DROP TRIGGER和CREATE TRIGGER无法包在一个事务里 - 若未提前备份
SHOW CREATE TRIGGER输出，重建时极易引入逻辑偏差或遗漏条件
别信“MySQL 8.0 支持 ALTER TABLE ... DISABLE TRIGGER”
网上流传的 ALTER TABLE t DISABLE TRIGGER tr 是伪代码，MySQL 官方从未实现该语法。所有版本（包括 8.0 和即将发布的 9.6.0）都不识别这条语句，执行会直接报错 ERROR 1064 (42000)。
- 混淆来源主要是 SQL Server 或 PostgreSQL 用户迁移时的误写
- 某些 ORM 或 GUI 工具（如 Navicat）的“禁用触发器”按钮，底层仍是重命名或变量控制，并非调用了原生语法
- 用
PREPARE+ 动态 SQL 包装错误语句，只会掩盖问题，不会让语法生效
真正关键的点在于：你得明确自己要的是“跳过执行”还是“彻底隔离”。前者靠变量或重命名就够了；后者不存在——MySQL 的触发器一旦存在，就绑定在表元数据上，删了才真消失。任何“禁用”都是应用层约定，不是内核能力。
