Error 2013 根本原因是 MySQL 服务端因空闲超时主动断连，非网络问题；需检查并调高 wait_timeout 和 interactive_timeout 参数，同时关闭 Navicat 自动断开空闲连接选项，并确保连接字符串正确配置时区与认证方式。

同步日志里只显示“Error 2013”怎么定位真实原因

这不是网络断开，而是 mysql 服务端主动踢掉了空闲连接。navicat 在解析大表中间结果或校验约束时可能几十秒没发新请求，触发了 wait_timeout 回收机制。
直接查日志没用，得看源库变量：

• 连上源库执行 show variables like '%timeout%';，重点看 wait_timeout 和 interactive_timeout
• 若值是 28800（8 小时），但同步中途就断，说明 navicat 实际建立的是交互式连接，且空闲时间已超阈值
• 临时调高：执行 set global wait_timeout = 86400; 和 set global interactive_timeout = 86400;
• 永久生效需改 /etc/my.cnf 或 my.ini 的 [mysqld] 段，加两行再重启 mysql

别设成 0——永不超时会堆积大量僵尸连接。

日志里一堆 “Duplicate entry” 却没在预览页看到被跳过的行

Navicat 的「数据同步预览」不展示被 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 跳过的记录，这些只会出现在完成后的「信息日志」里。
关键操作：

• 同步结束后，点开「信息日志」页签，手动搜索 Duplicate entry
• 每条警告形如 Duplicate entry '105' for key 'PRIMARY'，对应目标库已存在该主键
• 右键该行 → 「在目标库中打开」，确认这条记录是否本该存在（比如测试数据残留）
• 若确认是冗余数据，可提前在目标库 DELETE FROM table WHERE id IN (105, ...); 清理

注意：日志默认折叠，黄色警告容易被忽略，必须主动展开查看。

日志报错 “Incorrect datetime value: 'NULL'” 但源库 timestamp 字段明明有值

这是时区错位导致的类型校验失败，不是数据丢了。
典型表现：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 源库 created_at 是 2026-04-21 15:00:00，同步后目标库变 NULL 或 2026-04-21 07:00:00
• 错误发生在 STRICT 模式下，MySQL 拒绝写入非法时间值
• 根本原因是 Navicat 连接没指定时区，用系统本地时区解释 timestamp，而 MySQL 默认按 UTC 存、按会话时区转

修复方法：

• 编辑连接 → 「高级」页 → 在「连接字符串」末尾追加：&serverTimezone=Asia/Shanghai&useTimezone=true
• 阿里云 RDS 等环境可能需写成 &serverTimezone=GMT%2B8
• 改完必须右键连接 → 「编辑连接」→ 重输密码，否则参数不加载
• 验证：连上后执行 SELECT @@time_zone, NOW(), SYSDATE();，三个结果应一致

日志出现 “caching_sha2_password” 但连接测试能过

连接测试通过不代表同步能跑通——同步阶段会重建连接，而 Navicat 15 默认驱动不支持 MySQL 8.0+ 的默认认证插件。
现象：

• 连接测试成功，但同步结构或数据时突然卡住或报错
• 日志里没明确文字，但进程停滞在「正在获取表结构」阶段
• 后台 MySQL 错误日志可见 Plugin caching_sha2_password could not be loaded

解决：

• 编辑连接 → 「高级」页 → 勾选 Use MySQL Native Password
• 必须重新输入密码（仅勾选不重填无效）
• 如果 DBA 已卸载 mysql_native_password 插件，此选项无效，需联系 DBA 恢复插件或换跳板机

这个选项只影响新建会话，已存在的同步任务需取消重试。