跨库类型与精度校验
跨库同步时源端与目标端的类型并非一一对应，映射要逐字段核对。常见坑有三类：decimal 精度被截断、float 近似导致等值比较失败、char 定长自动补空格；此外还有字符集降级（utf8mb4 到 utf8 或 GBK）丢表情、时间精度由毫秒降为秒。这些差异常以“值被截断、科学计数、比较不等”的形式出现，归因很困难。
基本信息
| 核对对象 | 数值精度、字符长度、字符集、时间精度 |
|---|---|
| 高风险类型 | DECIMAL、FLOAT、CHAR、TIMESTAMP(3)、TEXT |
| 常见链路 | MySQL 8.0（utf8mb4）同步到 Hive / ODPS / ClickHouse |
| 校验手段 | 类型边界抽查、长度对比、聚合结果比对 |
| 配置要求 | 建表显式声明精度与字符集，映射配置纳入评审 |
典型使用场景
- 新链路建表时逐字段核对类型映射
- 对账出现 0.01 级差异时，排查是否用 float 存了金额
- 文本出现乱码或截断时，核对字符集与实际字节长度
- 时间字段丢毫秒导致去重失效时，检查时间类型精度
- 同步工具升级后回归，确认默认映射规则没有变化
类型边界抽查
类型边界抽查
SELECT order_id,
amount,
CAST(amount AS DECIMAL(20,6)) AS amount_hi, -- 高精度重算，与源端比对
LENGTH(store_name) AS len_raw, -- 字节长度，utf8mb4 中文占 3 字节
LENGTH(TRIM(store_name)) AS len_trim -- 去尾部空格，识别 CHAR 补空格
FROM ods_orders
WHERE dt = '2026-10-11'
LIMIT 20;精度与字符集核对
精度与字符集核对
-- 精度：聚合结果的尾数差异通常来自 float 近似
SELECT SUM(amount) AS sum_raw,
SUM(CAST(amount AS DECIMAL(20,6))) AS sum_dec
FROM ods_orders
WHERE dt = '2026-10-11';
-- 字符集：目标端不支持四字节字符时会被替换或截断
SELECT CHARSET(store_name) AS cs,
MAX(CHAR_LENGTH(store_name)) AS max_chars
FROM ods_orders
WHERE dt = '2026-10-11'
LIMIT 5;类型映射风险对照
| 源端类型 | 目标端常见问题 | 影响 |
|---|---|---|
| DECIMAL(18,2) | 落到 DOUBLE 或 FLOAT | 对账出现小数级差异 |
| CHAR(n) | 目标端按 VARCHAR 存储 | 比较时因尾部空格判为不等 |
| TIMESTAMP(3) | 落到秒级 TIMESTAMP | 毫秒级去重失效 |
| utf8mb4 文本 | 目标端 utf8 或 GBK | 表情与生僻字入库失败 |
| BIGINT | 落到 INT 或按字符串排序 | 数值溢出或被按字典序比较 |
建表显式声明精度与字符集；同步工具的类型映射配置要纳入评审，不要依赖默认推断。
MySQL 的 CHAR 在查询时会去掉尾部空格，存储时按长度补足；跨库比对前先 TRIM，否则同一个值会被判为不等。