navicat不支持自动匹配语义相同但字段名不同的列，必须手动在映射环节逐列绑定：点击源表右侧map按钮后，将order_no拖至sn、cust_id拖至customer_id；未映射源列被忽略，not null目标列若无默认值且未映射则报错；支持表达式如greatest(created_at, updated_at)；结构同步不处理语义等价，仅按物理结构重建，需关闭“删除多余对象”并手动调整ddl。
navicat 本身不支持自动匹配语义相同但字段名不同的列（比如源表的 user_name 和目标表的 full_name），必须手动在「映射」环节一一指定投射关系，否则同步会失败或写入 null。
数据同步时字段名不一致，必须用「映射」功能逐列绑定
Navicat 的「数据同步」界面里，点击某张源表右侧的 Map 按钮后，才能为每一列定义目标列。它不会根据类型或注释自动关联，只认字段名字面匹配。
- 如果源表有
order_no、cust_id，而目标表叫sn、customer_id，你得在映射列表里把order_no拖到sn上，cust_id拖到customer_id上 - 字段名完全不同时，不能留空或跳过——未映射的源列默认被忽略；未被任何源列映射的目标列，若定义为
NOT NULL且无默认值，同步会报错Column 'xxx' cannot be null - 支持表达式映射，比如把源表的
created_at和updated_at合并成目标表的event_time：填入GREATEST(created_at, updated_at)（MySQL）
结构同步无法解决字段名差异，只能重建或手动改 DDL
「结构同步」工具比对的是物理结构，不是语义。它看到源表 name VARCHAR(50)、目标表 full_name VARCHAR(100)，会当作两个不同字段处理，而不是“同义替换”。
- 若勾选了「删除目标中多余对象」，它可能直接删掉目标表的
full_name，再新建一个name字段，导致已有数据丢失 - 想保留
full_name并把源表name数据导进去？必须先关掉「删除」选项，然后在比对结果里手动删掉删字段的 SQL，再编辑建字段的 SQL，把name改成full_name - 字段类型长度也要自己核对：
name VARCHAR(20)映射到full_name VARCHAR(50)安全；反过来就可能触发Data too long for column
跨库或异构同步时，字段名不一致更易出错
从 MySQL 同步到 PostgreSQL，或 Oracle → SQL Server，字段名大小写、保留字、长度限制都不同，光靠映射还不够，得提前处理兼容性。
- PostgreSQL 默认小写字段名，MySQL 不区分——若源表有
OrderID，目标表建成了orderid，映射时得写成"OrderID"（加双引号）才能命中 - SQL Server 的
datetime和 MySQL 的DATETIME看似一样，但精度不同；映射时若目标列是datetime2(7)，源值可能被截断或四舍五入 - Oracle 的
NUMBER(10,0)映射到 MySQL 的BIGINT没问题，但若目标列是INT，大数值会溢出，错误信息是Out of range value for column 'xxx'
最麻烦的不是映射操作本身，而是字段语义是否真的一致——比如两张表都有 status，但一个用 0/1 表示启用/禁用，另一个用 'active'/'inactive'，这种必须用表达式转换，不能只靠名字匹配。
