Navicat 还原时无法跳过触发器，因其默认执行SQL中的所有语句；真正有效的绕过方式是：还原前DROP TRIGGER、还原后CREATE，或改用LOAD DATA INFILE（不触发），或手动提取并重置触发器。
Navicat 还原时无法直接“跳过触发器”执行，它默认会原样执行 SQL 文件里的 INSERT、UPDATE、DELETE 语句——而这些语句一旦命中带触发器的表，就会照常触发。所谓“跳过”，本质是让触发器不被执行，这只能靠数据库层控制，不是 Navicat 能开关的功能。
为什么还原时触发器会导致性能骤降
大批量数据还原（比如百万级 INSERT）遇上 AFTER INSERT 触发器，等于每插一行就额外执行一次触发逻辑：可能查关联表、写日志、调用函数、甚至发起远程请求。这不是“慢一点”，而是数量级恶化——100 万行 × 每行触发 50ms = 约 14 小时纯等待。
常见错误现象：
- Navicat 进度条卡在 20% 长达十几分钟，CPU 却没明显占用（实际是数据库在忙触发器）
- 还原中途报错
ERROR 1442: Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger（典型递归触发） - 目标库
slow_query_log里大量出现单行 INSERT 耗时超 1s 的记录
真正有效的三种绕过方式（按推荐顺序）
所有方法都要求你有目标库的 TRIGGER 权限，且操作前务必备份。
-
临时禁用触发器（MySQL 5.7.2+ / 8.0）：还原前在目标库执行
SET SESSION sql_log_bin = 0;（仅跳过二进制日志，不影响触发器）→ 不行；真正有效的是：SET @TRIGGER_CHECKS = 0;（MySQL 8.0.19+ 支持），但兼容性差；最稳做法仍是手动删再恢复 -
还原前 DROP TRIGGER，还原后再 CREATE：导出 SQL 时勾选「结构」和「数据」分开 → 先用 Navicat 执行结构 SQL（含
CREATE TRIGGER），立刻跟一句DROP TRIGGER IF EXISTS trigger_name;→ 再执行数据 SQL → 最后补回触发器。注意：触发器名需从结构 SQL 里手动提取，不能依赖 Navicat 自动识别 -
改写 INSERT 为 LOAD DATA INFILE（跳过触发器最彻底）：把导出的数据转成 CSV，用
LOAD DATA INFILE导入。该命令默认不激活触发器（除非显式加SET autocommit=1并启用特殊选项）。需确认目标库已开secure_file_priv，且文件路径对 MySQL 进程可读
Navicat 自带选项的误导性
Navicat 16+ 的「高级」还原选项里有「忽略外键检查」和「跳过重复键错误」，但没有「跳过触发器」开关。有人误点「禁用外键检查」以为能顺带压制触发器——不行。FOREIGN_KEY_CHECKS = 0 只影响约束校验，对触发器完全无效。
另外两个容易踩的坑：
- 勾选「执行每个语句后提交」会放大触发器开销：每行都 commit + 触发，比批量事务高 10 倍以上延迟
- 用 Navicat「数据传输」功能替代「SQL 还原」？它底层仍是逐行
INSERT，触发器照常运行，性能无改善
触发器本身不是敌人，但还原场景下它和批量操作天然互斥。别指望图形界面里点一下就解决——得拆解动作：要么让 SQL 绕过它（LOAD DATA），要么让环境暂时没有它（DROP + CREATE），这才是可控路径。临时关全局变量或改配置，在生产库上风险远高于收益。
