同步前脚本报错主因是外键约束未禁用及TRUNCATE不支持外键表，需在预处理脚本开头加SET FOREIGN_KEY_CHECKS=0;结尾加SET FOREIGN_KEY_CHECKS=1;并用DELETE替代TRUNCATE，同时确保表操作与Navicat同步配置一致。
同步前脚本报错：外键约束阻止 DELETE 或 INSERT
navicat 在执行结构/数据同步前运行预处理脚本（比如清空目标表、重置自增 id），但常因外键约束直接报 cannot delete or update a parent row: a foreign key constraint fails。这不是脚本写错了，而是 navicat 默认没关约束检查。
实操建议：
- 在预处理脚本最开头加：
SET FOREIGN_KEY_CHECKS = 0; - 所有操作完成后（比如删表、插数据之后），必须加：
SET FOREIGN_KEY_CHECKS = 1; - 别只在 Navicat 的“单条语句”模式里试——它默认每条语句单独提交，
SET不会跨语句生效；得把整个预处理逻辑包进一个DELIMITER $$ ... $$块，或直接粘贴为多行脚本并勾选「作为单个语句执行」 - MySQL 8.0+ 用户注意：
FOREIGN_KEY_CHECKS是会话级变量，只要连接没断，设一次就行；但 Navicat 同步任务可能新建连接，所以每次预处理脚本都得显式设置
预处理脚本里用 TRUNCATE 报错：Cannot truncate a table referenced in a foreign key constraint
TRUNCATE TABLE 比 DELETE FROM 快，但它会绕过触发器、重置 AUTO_INCREMENT，且**不支持带外键引用的表**——哪怕你已经关了 FOREIGN_KEY_CHECKS，MySQL 仍会拒绝 TRUNCATE。
实操建议：
- 一律改用
DELETE FROM <table_name>;</table_name>清空数据 - 如果要重置自增 ID，后续补一句：
ALTER TABLE <table_name> AUTO_INCREMENT = 1;</table_name> - 别依赖 Navicat 自动勾选「清空表」——它背后可能偷偷用
TRUNCATE；手动写脚本时，看到TRUNCATE就替换成DELETE - 对大表慎用
DELETE FROM：没 WHERE 条件会锁全表，同步窗口长的话，考虑加LIMIT分批删，或改用DROP TABLE + CREATE TABLE（需确保建表语句完整）
预处理脚本执行后，同步主流程报错：Table doesn’t exist 或 Column count doesn’t match
这通常不是脚本本身语法错，而是 Navicat 同步逻辑和脚本副作用冲突：比如你在预处理里删了某张表，但 Navicat 的同步配置里仍勾选了「同步该表结构」，它就会在后续步骤尝试往不存在的表里写字段定义，或者拿旧表结构去比对新数据。
实操建议：
- 预处理脚本里删表 / 改表后，立刻检查同步向导里的「对象选择」页——确认被删/改的表是否还在勾选状态；若已不存在，就取消勾选，否则 Navicat 会坚持同步它
- 如果脚本里重建了表（如
DROP TABLE IF EXISTS; CREATE TABLE...），确保CREATE TABLE语句和 Navicat 当前读取的源结构完全一致（尤其字段顺序、默认值、注释），否则数据同步阶段会因列数/类型不匹配失败 - Navicat 16+ 对临时表支持变差：预处理里建的
TEMPORARY TABLE在同步主流程中不可见，别指望用它中转数据
MySQL 5.7 升级到 8.0 后，预处理脚本里用 GROUP BY 报错：Expression #1 of SELECT list is not in GROUP BY clause
这是 SQL 模式变更导致的——MySQL 8.0 默认启用 ONLY_FULL_GROUP_BY，而很多老脚本习惯写 SELECT a, b FROM t GROUP BY a（只按 a 分组却选了 b）。Navicat 预处理脚本一跑就崩。
实操建议：
- 在预处理脚本开头加：
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')); - 更稳妥的做法是：重写有问题的
GROUP BY查询，确保SELECT列要么在GROUP BY中，要么用聚合函数包裹（如MAX(b)） - 别在脚本里用
SET GLOBAL sql_mode——需要 SUPER 权限，Navicat 连接用户一般没有；只设会话级即可 - 这个错误容易被忽略，因为只在脚本含聚合查询时才触发，平时测试可能没覆盖到
预处理脚本不是“随便写几行 SQL 就能跑通”的环节，它的执行环境、生命周期、与 Navicat 同步引擎的耦合度，比想象中 tight 得多。最容易漏的是会话变量作用域和表状态同步——脚本里删了表，Navicat 不知道；脚本里关了约束，Navicat 下一条语句可能换连接又开了。盯住这两点，大部分报错就清楚源头在哪了。
