UNION ALL字段类型不一致会直接报错或导致数据错列；MySQL和PostgreSQL均要求对应位置列类型兼容、顺序严格一致，必须显式CAST或::转换，不可依赖隐式转换。
UNION ALL 字段类型不一致会直接报错或结果错乱
MySQL 和 PostgreSQL 在 UNION ALL 时要求对应位置的字段**类型兼容且顺序严格一致**，不是“差不多就行”。常见错误包括：ERROR 1267 (HY000): Illegal mix of collations（字符集校对冲突）、ERROR: UNION types integer and text cannot be matched（PostgreSQL 类型强校验失败）。字段顺序错位（比如左表是 id, name，右表是 name, id）不会报错，但数据会错列——id 值被当 name 显示，极易漏查。
- 必须逐列显式对齐：用
CAST或::强制转为目标类型，不能依赖隐式转换 - 字符串字段要统一
CHARACTER SET和COLLATION，否则即使都是VARCHAR也会失败 - 数值字段注意精度丢失：比如把
FLOAT转DECIMAL(10,2)时，原值123.456会被截断为123.46 - 空值处理要显式：
NULL的类型由上下文推导，建议写成NULL::TEXT或CAST(NULL AS INTEGER)明确意图
JOIN 关联字段类型不一致导致索引失效甚至匹配错误
类型不一致的 JOIN（如 user.id BIGINT 关联 order.user_id VARCHAR）在 MySQL 中会触发隐式转换，执行计划里出现 type: ALL、key: NULL 就是典型信号。更危险的是语义错误：MySQL 把 '1abc'、'1 '、'1e2' 全当成 1 匹配，一条记录可能连出多条虚假关联。
- 别在
ON条件里用CAST(order.user_id AS SIGNED)—— 这样写索引照样失效 - 真正能走索引的解法只有一种：
ALTER TABLE order MODIFY user_id BIGINT UNSIGNED NOT NULL - 改之前务必清理脏数据：
SELECT COUNT(*) FROM order WHERE user_id REGEXP '[^0-9]'扫描非法字符 - PostgreSQL 更严格：
order.user_id::BIGINT遇到非数字直接报错，必须先NULLIF(TRIM(user_id), '')::BIGINT
历史表和实时表 UNION 视图必须加 source_type 和显式 CAST
用 CREATE VIEW 合并历史分区表（如 sales_202310）和实时表（如 sales_current）时，字段名、时间精度、状态语义三处不兼容最常引发问题。比如历史表用 event_time TIMESTAMP（秒级），实时表用 created_at TIMESTAMPTZ（微秒+时区），直接 UNION ALL 会因精度/时区隐式转换失败。
- 时间字段必须统一别名 + 强制转换：
created_at::TIMESTAMP WITHOUT TIME ZONE AS event_time - 每列都加
CAST：amount::DECIMAL(10,2)，避免 PostgreSQL 因类型推导失败而中断 - 必须加
'historical'::TEXT AS source_type字段——不只是调试用，下游权限控制、ETL 分流都依赖它 - 视图不解决数据一致性：实时表延迟可能导致同一订单在历史表和实时表里同时存在，需靠归档逻辑保障“追加写”语义
跨年对比 JOIN 必须统一年份字段物理类型
用 LEFT JOIN 对比 t_2022 和 t_2023 表时，如果一边年份是 INT，另一边是 CHAR(4) 或 DATE，匹配结果为空不是数据问题，而是类型不匹配导致优化器放弃索引、全表扫描后仍无法对齐。
- 优先改表结构：
ALTER TABLE t_2023 MODIFY year_col INT，而不是在 JOIN 里写CAST(t_2023.year_col AS SIGNED) - MySQL 不支持
FULL OUTER JOIN，模拟时也要确保两边 JOIN 键类型一致，否则UNION ALL后的去重或过滤逻辑会出错 - 同比计算（如
(sales_2023 - sales_2022) / NULLIF(sales_2022, 0)）必须放在SELECT或WHERE，绝不能塞进ON条件 - 检查
EXPLAIN中type是否为ref或eq_ref，这是类型对齐成功的唯一可靠指标
字段类型不一致从来不是“SQL 写得不够巧”的问题，而是数据契约没对齐。临时 CAST 或函数包装顶多撑到下一次数据量翻倍，真正要动的是表定义本身——哪怕只是改一个字段的 COLLATE，也得全链路验证索引、外键、视图、ORM 映射是否同步生效。
