字段映射是有损决策过程，需兼顾类型、语义、约束和行为四层对齐，否则将导致截断、错乱、隐式转换异常及生产告警。
字段类型映射不是“自动对齐”，而是有损决策过程
异构数据库之间没有天然兼容的字段类型体系，比如 mysql 的 tinyint(1) 常被业务当布尔用，但 postgresql 没有等价布尔整型，oracle 更不认 auto_increment；sql server 的 datetime2 精度远超 mysql 的 datetime。直接按名字或长度硬映射，大概率导致插入失败、精度截断、时区错乱或隐式转换异常。
- 别依赖工具“自动推荐”的目标类型——
Tapdata Cloud的模型推演虽用TapType中间层打分排序，但分数接近的类型（如VARCHAR(255)vsTEXT）在目标库约束下行为可能完全不同 - 测试库必须用真实生产字段值做校验：比如源库某
DECIMAL(10,2)字段实际存了99999999.99，目标库若映射成DECIMAL(8,2)，同步时不会报错，但数据会被静默截断 - 枚举类字段（
ENUM、DOMAIN）不能只映射类型，要同步迁移值域定义，否则目标库查出来全是NULL或默认值
如何让测试库映射结果可验证、可回滚
测试环境不是“跑通就行”，它得能暴露生产上线前所有类型失配问题。核心是把字段映射变成可版本化、可比对、可重放的操作。
- 用 DDL 脚本固化映射逻辑：从
CREATE TABLE语句中提取源字段定义，人工编写目标库建表语句，而非靠同步工具自动生成——这样每次变更都有 git diff 可追溯 - 在测试库执行
SELECT校验脚本，重点查三类异常：COUNT(*)是否一致、COUNT(NULL)在目标字段是否异常增多、MAX(LENGTH(col))是否超出目标字段长度 - 禁用目标库的
STRICT_TRANS_TABLES类严格模式（如 MySQL），否则类型转换失败会中断同步；但测试阶段要临时开启，主动暴露问题
无损发布的本质是“双写+渐进切流”，不是字段映射做完就完事
字段映射只是静态结构准备，无损发布的关键在于运行时数据流向控制。生产环境不能停写，也不能容忍“映射后字段变长导致 UPDATE 失败”这类问题。
- 上线前在应用层加双写逻辑：新老库同时写入，但只从老库读——此时字段映射必须保证老库字段能无损转成新库字段（例如老库
VARCHAR(50)→ 新库VARCHAR(100)，不能反着来） - 字段精度升级（如
INT→BIGINT）可立即执行；降级（BIGINT→INT）必须先确认全量数据最大值，否则切流后写入直接报错 - 时间类型务必统一时区处理：
MySQL默认无时区，PostgreSQL的TIMESTAMP WITH TIME ZONE会自动转 UTC，应用写入时若未显式指定时区，测试库看着正常，生产切流后时间全偏 8 小时
最容易被忽略的坑：约束和默认值根本不会自动映射
工具界面里只显示字段名、类型、长度，但 NOT NULL、CHECK、DEFAULT CURRENT_TIMESTAMP、GENERATED ALWAYS AS 这些才是上线后崩盘的导火索。
-
Oracle的SYSDATE默认值，在PostgreSQL里得手动改成NOW()，且函数签名不兼容（SYSDATE + 1≠NOW() + INTERVAL '1 day'） -
MySQL的ON UPDATE CURRENT_TIMESTAMP行为，在SQL Server中需用触发器模拟，否则测试库数据“看起来一样”，生产更新时时间戳永远不刷新 - 外键约束名在异构库中不保留，但引用关系必须重建；如果源库没建外键，测试时一切正常，生产开启级联删除后才发现关联数据被误删
字段映射不是配置一次就能躺平的事，它是结构、语义、约束、行为四层对齐的过程。少对齐一层，上线那天就会多一个凌晨三点的告警。
