Navicat同步前必须手动确认并统一字段类型，不自动转换；源TEXT→目标VARCHAR(20)会因截断报错，需用DESCRIBE/\d比对类型长度、NULL约束、字符集及数值精度，并在映射中用UNIX_TIMESTAMP、CASE、REPLACE等表达式兜底适配。
同步前必须手动确认并统一字段类型
navicat 不会自动转换字段类型，它只做值的搬运。如果源表 user_name 是 varchar(50)，目标表对应列是 text，同步能成功；但反过来——源是 text、目标是 varchar(20)，就会触发 data truncation: data too long for column 错误，整行跳过或中断（取决于配置）。
实操建议：
- 用
DESCRIBE table_name（MySQL）或\d table_name（PostgreSQL）分别查源、目标表字段定义，逐列比对类型、长度、是否允许 NULL、默认值 - 特别注意数值类字段：
TINYINTvsBOOLEAN、DATETIMEvsTIMESTAMP、DECIMAL(10,2)vsFLOAT，精度丢失不可逆 - 字符集也要一致：源是
utf8mb4、目标是utf8，含 emoji 或四字节字符时会变成?或报错 - 别依赖 Navicat 的「自动创建目标表」——它常把 JSON 建成
LONGTEXT，把UUID建成VARCHAR(36)而非CHAR(36)
映射阶段用表达式兜底兼容性问题
当无法修改目标表结构（比如生产库权限受限），就得在 Navicat 同步的「映射」界面里做适配。点击源表右侧的 Map 按钮后，对不匹配字段写转换逻辑：
常见场景：
- 源字段是
created_at DATETIME，目标列是event_time INT（Unix 时间戳）→ 映射表达式填UNIX_TIMESTAMP(created_at) - 源
status TINYINT存 0/1，目标status ENUM('active','inactive')→ 填CASE WHEN status=1 THEN 'active' ELSE 'inactive' END - 源
phone VARCHAR(20)可能含空格或括号，目标要求纯数字 → 填REPLACE(REPLACE(REPLACE(phone, ' ', ''), '-', ''), '(', '') - 目标列定义为
NOT NULL，但源值可能为NULL→ 必须写默认值，如IFNULL(phone, '')或COALESCE(email, 'unknown@example.com')
启用跳过错误 + 日志反查，避免静默丢数据
即使做了类型检查和映射，仍可能因隐式转换失败（如字符串转数字时含字母）、时区偏移、BOM 头导致同步中断或写入异常值。Navicat 默认失败即停，必须主动干预：
- 同步设置中务必勾选
跳过错误记录（Skip error records），否则一行失败整批终止 - 同步完成后立刻打开底部
日志面板，搜索关键词：Data truncation、Incorrect integer value、Truncated incorrect、Invalid date - 对报错行，回到源库执行验证 SQL：
SELECT id, phone FROM source_table WHERE id IN (123, 456);，人工确认原始值是否真有问题 - 若发现批量问题（如某字段全含前导空格），不如先在源库用
UPDATE清洗，再同步，比在映射里加函数更可靠
跨数据库迁移时类型映射没有银弹
从 SQL Server 同步到 MySQL，或 PostgreSQL 到 SQLite，字段类型差异是系统级的。Navicat 不提供自动映射表，靠的是你提前约定规则：
-
SQL Server's UNIQUEIDENTIFIER→ MySQL 目标列必须是CHAR(36)或BINARY(16)，不能用UUID()函数生成（那是插入时行为，同步是搬运） -
PostgreSQL's JSONB→ MySQL 目标必须是JSON类型，且 MySQL 版本 ≥ 5.7.8；若目标仍是TEXT，后续->操作全返回NULL -
Oracle's NUMBER(10)→ 若映射到 MySQLINT，超限值（>2147483647）会变负数或截断，必须改用BIGINT - 别碰
GEOMETRY、XML、HSTORE这类专有类型，Navicat 基本不识别，同步会直接失败
类型不一致不是配置开关能解决的事，它卡在建表那一刻——没手动对齐结构，后面所有同步动作都在沙上筑塔。
