数据同步时区、字符集与精度问题排查

先说结论：同步任务"成功"不等于数据可信。时间戳整体偏移 8 小时是时区语义问题，中文乱码或被截断是字符集字节账问题，小数尾数不对是数值类型映射问题——三类根因各有一套检查动作；还有第四种更隐蔽的情况是列映射错位，它不报错、不告警，只静默产出脏数据，必须靠对账才能发现。下面按根因分类给出检查清单和验证方法。

一、时间戳偏移：TIMESTAMP 与 DATETIME 的语义差

MySQL 的 TIMESTAMP 内部按 UTC 存储、读写时按会话 time_zone 转换，DATETIME 则原样存字面值、不做任何时区转换。8 小时偏移几乎总是这么来的：写入端连接按东八区写入，读取端连接声明成 UTC（或反过来），TIMESTAMP 列在两次转换之间被平移了 8 小时；而 DATETIME 列如果在同步链路里被当成"带时区的时间"再转一次，也会出现同样的偏移。MySQL 时间类型语义的细节可参考 MySQL 时间类型辨析。

检查动作：

• 对同一行记录分别在源端和目标端执行 SELECT @@session.time_zone, @@global.time_zone，再核对 JDBC 驱动连接串里的时区参数（如 serverTimezone），三者必须统一。
• 抽一行原始数据在两端分别读出字面值，先确认偏移是恒定 8 小时还是随季节变化——恒定偏移指向连接时区不一致，随季节变化指向目标端又按本地时区做了一次转换。
• 明确业务语义：事件发生时间用 DATETIME 或整数时间戳存储、约定业务时区；只有"记录入库时间"适合 TIMESTAMP。跨库同步时优先让链路透传字面值，禁止隐式时区转换。

二、乱码与截断：字符集的字节账

字符集的坑本质是字节长度：utf8mb3（常被简称为 utf8）每字符最多 3 字节，emoji 和部分生僻字需要 4 字节，写入时要么报错、要么在非严格模式下被静默截断；gbk 每字符 2 字节，latin1 只有 1 字节，把中文数据同步进 latin1 列必然乱码。另外 VARCHAR(N) 的 N 是字符数，行宽上限却按字节计算，宽字符集下同样的 N 占用更多字节，索引前缀长度限制也按字节走，建表时"看起来够长"的列实际可能放不下。编码与字符集的系统性辨析可参考 字符集与编码问题梳理。

检查动作：

• 核对源端、目标端、连接三层字符集：SHOW CREATE TABLE 看列与表的默认字符集，SHOW VARIABLES LIKE 'character_set%' 看服务器和连接字符集，再看同步工具连接串是否显式指定了字符集。
• 对疑似截断的列做长度对账：两端分别取 CHAR_LENGTH（字符数）和 LENGTH（字节数），同值的两列比值不一致，通常意味着中途发生了字符集转换或截断。
• 优先统一到 utf8mb4，目标端列宽按最长业务值的 4 字节倍数留余量。

三、小数精度丢失：数值类型映射

DECIMAL(p,s) 是精确定点数，FLOAT/DOUBLE 是近似浮点；同步链路里任何一处把 DECIMAL 映射成浮点类型，尾数就会漂移（典型表现是金额从 1234567.89 变成 1234567.8899999）。另一类问题是标度不匹配：源端 DECIMAL(20,4) 被映射到目标端 DECIMAL(10,2)，小数位被截或整数位溢出；还有 BIGINT UNSIGNED 映射进有符号列、BIGINT 映射到双精度（超过 2^53 后整数不再精确）。

检查动作：

• 导出两端建表语句逐列比对类型与标度，重点确认 DECIMAL 的 (p,s) 是否原样保留，UNSIGNED 属性有没有在迁移中丢失。
• 对金额列做 SUM 对账而不是抽样目测：两端 SUM、MIN、MAX 不一致就说明映射有问题。
• 定死规则：精确数值一律 DECIMAL 透传；确实要落浮点的（如科学计算中间值）在任务文档里注明精度损失是预期内行为。

四、列映射错位：不报错的静默脏数据

如果同步工具按列顺序而非列名映射，源端加列、删列或调整列序后，数据会被灌进错误的列——字符串灌进数值列在非严格模式下可能变成 0，数值灌进字符串列只是变成"看起来像数字的文本"，任务照样显示成功。MySQL 默认配置下 sql_mode 若不含 STRICT_TRANS_TABLES，截断和无效值只产生警告不报错，这类脏数据连错误日志都不会留。这是四类问题里唯一无法靠单点检查发现的，只能靠对账。

验证方法：

• 行数对账之外，按主键抽样若干行逐列比对：数值列比 SUM，文本列比去空格后的值，时间列比字面值。
• 在目标端跑探针查询验证分布特征，例如 SELECT COUNT(*) FROM t WHERE status NOT IN ('a','b','c')，合法值枚举一旦出现表外值，基本可断定列错位或映射错。
• 给任务加"哨兵行"：源端造一行可识别的测试数据（主键取极值、每列取特征值），同步后在目标端逐列校验落点，任何后续结构变更都会被哨兵行暴露。

迁移类工具的官方映射规则可对照 数据迁移的类型映射说明 逐列核对。

五、排查顺序

按修复代价从低到高：

• 先查连接与时区参数（第一类），改动最小、命中率最高。
• 再查字符集三层配置（第二类），多数乱码在这一层解决。
• 然后逐列比类型与标度（第三类），重点扫金额列和大整数列。
• 最后做行级抽样与哨兵对账（第四类），确认没有列错位。
• 每修完一层就回放一批历史数据重验，避免只修了表现没修根因。