MySQL 8.0+ 不支持 DISABLE TRIGGER 语法，唯一可靠方案是 RENAME TRIGGER；需带数据库前缀、加时间戳后缀，通过动态SQL批量处理，并务必验证恢复后的触发器是否生效。
MySQL 8.0+ 没有 ALTER TABLE ... DISABLE TRIGGER 语法
你查到的 ALTER TABLE table_name DISABLE TRIGGER trigger_name 或 ALTER TRIGGER trigger_name DISABLE 在 MySQL 中**根本不存在**——这些是 SQL Server 的语法，被大量博客错误搬运。MySQL 官方文档从未支持该写法，执行会报错 ERROR 1064 (42000) 或 ERROR 1357 (HY000)。别信网上那些“亲测有效”的截图，基本都是在伪造环境或混淆版本。
真正能绕过触发器的唯一可靠方式：RENAME TRIGGER
MySQL 自 5.7.2 起支持 RENAME TRIGGER，这是目前最安全、可逆、无需额外权限的方案。原理很简单：触发器名必须全局唯一且 DML 不显式引用它，重命名后 MySQL 在执行 DELETE / INSERT 时就匹配不到原名，自然不触发。
- 重命名必须带数据库名前缀，例如
RENAME TRIGGER `mydb`.`trg_log_after_del` TO `mydb`.`trg_log_after_del_disabled_20260614`;；漏掉`mydb`.会报ERROR 1357 - 时间戳后缀（如
_20260614）防止重复执行冲突，尤其在自动化脚本中很重要 - 重命名不影响触发器定义本身——函数、表、变量依赖全保留，恢复时直接 rename 回去即可
- 不要用
DROP TRIGGER：重建时容易遗漏DELIMITER、权限丢失、或因字符集/SQL_MODE 差异导致语法错误
批量禁用当前库所有触发器的动态 SQL 写法
手动一个个 rename 太慢，尤其当有十几个触发器时。用 information_schema.TRIGGERS 自动生成语句：
SELECT CONCAT( 'RENAME TRIGGER `', TRIGGER_SCHEMA, '`.`', TRIGGER_NAME, '` TO `', TRIGGER_SCHEMA, '`.`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 语句，复制粘贴进客户端就能跑。注意：TRIGGER_SCHEMA = DATABASE() 是硬性过滤条件，避免跨库误操作。
导数完成后必须恢复，且验证不能跳过
重命名只是“失效”，不是删除，所以恢复就是反向 rename。但这里容易出问题：
- 你得保存好原始映射关系——执行禁用前先跑一次
SELECT TRIGGER_NAME, ACTION_TIMING, EVENT_MANIPULATION FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = DATABASE(); - 恢复时别只改名，还要确认触发器是否真生效：插入一条测试数据，查日志表或统计字段是否更新
- 如果触发器里用了
@user_var或临时表，重命名不影响逻辑，但要注意会话级变量作用域——别指望靠设@enable_trigger=0来控制，那只是应用层 hack，不可靠且难维护
真正麻烦的点不在 rename 本身，而在恢复后没人检查它是否还在工作。线上表一旦漏掉一个 AFTER DELETE 日志触发器，数据溯源就断了。
