mysql 8.0+ 不支持 set disabled，禁用触发器需用 rename trigger 重命名（如 trg_disabled_原名_时间戳），仅限同库操作；恢复时反向重命名，执行前须导出原名映射并测试闭环。
MySQL 8.0+ 没有原生 SET DISABLED 语法，别踩这个坑
MySQL 不支持像 SQL Server 那样用 DISABLE TRIGGER ALL 或 SET DISABLED 临时禁用触发器。所谓“批量禁用”本质是**重命名触发器使其失效**（因为触发器名必须唯一且 DML 语句中显式引用名的场景极少），或**临时删除再恢复**——后者风险高，不推荐；前者可控、可逆、无权限额外要求。
生成重命名触发器的动态 SQL：只操作当前数据库
核心思路是查 information_schema.TRIGGERS，拼出把每个触发器重命名为 trg_old_原名_时间戳 的 RENAME TRIGGER 语句。注意：RENAME TRIGGER 是 MySQL 5.7.2+ 才支持的语法，且**不能跨库操作**，所以必须确保 TRIGGER_SCHEMA = DATABASE()。
执行前建议先备份触发器定义：
SELECT CONCAT('SHOW CREATE TRIGGER `', TRIGGER_NAME, '`;')
FROM information_schema.TRIGGERS
WHERE TRIGGER_SCHEMA = DATABASE();
生成禁用语句（带防错和时间戳）：
SELECT CONCAT( 'RENAME TRIGGER `', TRIGGER_NAME, '` TO `trg_disabled_', TRIGGER_NAME, '_', DATE_FORMAT(NOW(), '%Y%m%d_%H%i%s'), '`;' ) AS ddl FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = DATABASE() ORDER BY TRIGGER_NAME;
- 输出每行都是独立的
RENAME TRIGGER语句，可直接复制执行 - 重命名后原触发器逻辑完全不生效，DML 不会触发它
- 时间戳确保重命名唯一，避免重复执行冲突
- 不依赖存储过程或变量，纯 SELECT 可在任何客户端运行
如何安全恢复触发器（不是“启用”，而是还原）
重命名不是删除，恢复就是再 rename 回去。但你得记住原名——所以执行禁用前务必导出映射关系：
SELECT
TRIGGER_NAME AS original_name,
CONCAT('trg_disabled_', TRIGGER_NAME, '_', DATE_FORMAT(NOW(), '%Y%m%d_%H%i%s')) AS disabled_name
FROM information_schema.TRIGGERS
WHERE TRIGGER_SCHEMA = DATABASE();
之后恢复时，用类似逻辑反向生成 RENAME TRIGGER `新名` TO `原名`。注意：RENAME TRIGGER 要求目标名不存在，所以如果原名已被占用（比如手动重建过），必须先 DROP 再 RENAME，或改用其他策略。
- 不要依赖 SHOW CREATE TRIGGER 输出自动还原——它不含触发器名，只含定义
- 若需自动化恢复，建议把上面的映射结果存为临时表或本地 CSV
- 生产环境执行前，务必在测试库验证 rename + restore 流程是否闭环
替代方案：用 SQL_MODE 或应用层开关？不现实
有人想通过设置 SQL_MODE 或加全局变量来“开关”触发器，MySQL 官方不提供这类机制。触发器是强制执行的，除非你：
- 修改触发器体，开头加
IF @disable_triggers THEN LEAVE proc_label; END IF;，并提前SET @disable_triggers = 1;——但这要改所有触发器源码，且影响所有会话 - 在应用代码里统一加开关标记，让触发器读取业务表状态判断是否跳过 —— 这已超出数据库职责，耦合度高
- 用代理层（如 ProxySQL）拦截并重写 DML —— 架构复杂，维护成本陡增
所以，对绝大多数运维/发布场景，“rename 禁用 → 操作数据 → rename 恢复”仍是平衡安全性、简洁性和兼容性的最优解。关键点就一个：RENAME TRIGGER 必须在目标库上下文中执行，且不能有同名冲突。
