navicat结构同步时触发器引发死锁的主因是重建触发器触发隐式mdl锁，或definer用户缺失导致创建失败并阻塞dml；应取消options中generate triggers选项并手动取消source objects中所有触发器勾选，禁用外键检查对此无效。
Navicat结构同步时触发器为何会引发死锁
触发器本身不直接导致死锁，但Navicat在结构同步过程中若尝试重建或替换触发器，可能触发目标库的隐式元数据锁（MDL lock），尤其当目标表正被其他事务读写时。更常见的是：源库触发器含DEFINER='admin'@'localhost'，而目标库无该用户，MySQL 创建后标记为 INVALID，后续任何对该表的 DML 都可能因触发器校验失败而卡住，表现类似死锁（实际是等待超时或阻塞）。另外，跨版本同步（如 MySQL 5.7 → 8.0）时，Navicat 可能生成带SQL SECURITY DEFINER但缺失权限检查的语句，服务端拒绝执行并挂起连接。
结构同步中彻底跳过触发器的两种可靠方式
Navicat 不提供“全局禁用触发器同步”的开关，必须从配置层和操作层双管齐下：
- 进入
Tools → Options → Data Synchronization → Advanced，取消勾选Generate triggers—— 这是源头控制，确保同步脚本里根本不出现CREATE TRIGGER语句 - 比对完成后，在结构同步界面左侧的
Source Objects树中，手动展开Triggers节点，逐个取消勾选所有触发器（支持 Ctrl 多选）—— 这步不能省，因为 Options 设置只影响新生成逻辑，已缓存的比对结果仍可能包含触发器 - 若目标库已有同名触发器且你确认无需更新，可在同步前手动执行
DROP TRIGGER IF EXISTS trigger_name，避免 Navicat 尝试CREATE OR REPLACE引发权限或定义冲突
为什么“禁用外键检查”不能解决触发器问题
很多人误以为 SET FOREIGN_KEY_CHECKS = 0 能绕过触发器限制，但它只关闭外键约束验证，对触发器的创建、激活、执行完全无效。触发器依赖的是 TRIGGER 权限和 DEFINER 用户存在性，不是外键机制。实测中，即使关了外键检查，遇到 ERROR 1449 (HY000): The user specified as a definer ('admin'@'localhost') does not exist 仍会中断同步。真正有效的兜底动作是：在目标库提前创建好对应 DEFINER 用户，或改用 SQL SECURITY INVOKER 重建源触发器（需手动导出 SHOW CREATE TRIGGER 后编辑）。
数据同步场景下触发器的干扰更隐蔽
数据同步（Data Sync）虽不重建触发器，但若目标表有 BEFORE INSERT 触发器，它会在 Navicat 执行每条 INSERT 时被调用。这时问题不在同步工具本身，而在触发器逻辑是否兼容批量插入——比如触发器里用了 SELECT ... FOR UPDATE 或调用了未授权函数，就会在某一行卡住，整个同步停滞。应对方法不是跳过触发器，而是：
- 同步前在目标库临时禁用：
ALTER TABLE table_name DISABLE TRIGGER trigger_name（PostgreSQL）或SET @trigger_disabled = 1（MySQL 需触发器内判断变量） - 确认触发器不含
INSERT/UPDATE自身表的操作（易造成递归锁） - 用 Navicat 的「保存为 SQL 文件」功能导出脚本，在 INSERT 前手动加
DISABLE TRIGGER，执行后再ENABLE
触发器不是结构同步的“可选项”，它是元数据的一部分；跳过它的唯一安全路径，是明确告诉 Navicat 不要碰，而不是指望它自动识别哪些该留、哪些该删。
