mysql触发器在批量导入时逐行执行，万级数据触发万次，导致io、锁、wal日志全面拖垮；因mysql不支持disable trigger语法，唯一可靠方案是用rename trigger临时重命名（须带数据库前缀并加时间戳后缀），禁用后须验证生效且需人工补全缺失业务逻辑。
因为MySQL触发器在批量导入时会逐行执行，万级数据就触发万次，哪怕只是写一条日志，也会把导入耗时拉长数倍甚至十倍以上——这不是“慢一点”，而是IO、锁、WAL日志全被拖垮的系统性瓶颈。
MySQL没有DISABLE TRIGGER语法，别信网上那些错误命令
你搜到的 ALTER TABLE t DISABLE TRIGGER tr_name 或 DISABLE TRIGGER ALL ON t 全是SQL Server语法，在MySQL里直接报错 ERROR 1064 或 ERROR 1357。官方文档从5.7到8.0.33都未支持该功能。执行失败还自以为“禁用了”，结果导入时触发器照常狂跑，是最危险的情况。
唯一可靠方案：用RENAME TRIGGER临时绕过
MySQL自5.7.2起支持 RENAME TRIGGER，原理是让触发器名失效，DML语句找不到匹配名就不触发。操作必须带数据库前缀，否则报错：
RENAME TRIGGER `mydb`.`trg_audit_after_insert` TO `mydb`.`trg_audit_after_insert_disabled_20260906`;- 导入完成后恢复：
RENAME TRIGGER `mydb`.`trg_audit_after_insert_disabled_20260906` TO `mydb`.`trg_audit_after_insert`; - 时间戳后缀（如
_20260906）防止脚本重复执行冲突 - 不能用
DROP TRIGGER+CREATE TRIGGER：重建易丢DELIMITER、权限、字符集配置，且无法保证定义完全一致
禁用后必须验证是否真生效
很多人执行完RENAME就去导入，结果发现audit_log表还在疯狂写入——常见原因有：
- 没加数据库前缀，语句静默成功但没作用到目标触发器
- 在自动提交模式下操作，重命名只对当前会话有效，而导入工具另起连接
- 触发器名大小写不一致（比如建的是
TRG_LOG，却重命名trg_log） - 验证方式很简单：
SELECT TRIGGER_NAME FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'mydb' AND TRIGGER_NAME LIKE '%disabled%';看是否真出现在结果里
真正难的不是怎么禁用，而是禁用期间发生的业务逻辑缺失（比如状态没同步、审计字段为空）需要人工补全——这个动作常被跳过，最终导致线上数据不一致，比慢更致命。
