UNION ALL视图要求列数、顺序、类型三者严格一致，否则建视图直接报错；需显式写字段、用CAST/::统一类型、补NULL占位、逐个检查索引，且字段顺序错一位即失败。
视图不能自动适配字段差异，必须手动对齐类型、别名和空值行为——否则建视图时直接报错，或查出来数据错位、类型冲突。
UNION ALL 合并多源表时字段类型不一致就失败
MySQL 和 PostgreSQL 都要求 UNION ALL 中每个子查询的对应列类型严格兼容。比如一个来源用 INT 存用户 ID，另一个用 VARCHAR，不显式转换就会报 ERROR: UNION types integer and text cannot be matched。
- 所有字段必须按顺序一一对应，不能靠列名匹配
- 用
::TEXT（PostgreSQL）或CAST(id AS CHAR)（MySQL）统一基础类型 - 数值类字段建议转成
NUMERIC(18,2)而非FLOAT，避免精度漂移 - 时间字段优先转成
TIMESTAMP WITHOUT TIME ZONE，避免时区隐式转换出错
字段名/顺序不一致导致上层应用取值错乱
视图字段名以第一个 SELECT 的别名为准，后续子句即使写了不同别名也无效。如果某来源表把 user_name 改成 full_name，而你没在视图里显式重命名，那视图对外暴露的仍是旧字段名，但实际值可能来自错误列。
- 每个
SELECT都要写全字段 +AS别名，禁止用* - 推荐在视图定义开头加注释说明各来源字段映射关系，例如：
-- src_a: user_name → name; src_b: full_name → name - 若某来源缺失某字段，必须用默认值填充，如
'N/A'::TEXT AS category或NULL::BOOLEAN AS is_premium
NULL 行为和默认值不统一引发业务逻辑误判
Oracle 默认字符串比较忽略尾部空格，MySQL 严格区分；SQL Server 把空字符串当 NULL 处理，PostgreSQL 不会。这些差异在视图里不处理，会导致 WHERE name = '' 在不同来源返回结果不一致。
- 统一用
COALESCE(email, '')替代裸字段，确保空值有确定语义 - 布尔类字段不要依赖底层
TINYINT/CHAR(1)/BOOLEAN差异，一律转成CASE WHEN status IN ('Y','1','t') THEN TRUE ELSE FALSE END AS is_active - 数值字段避免直接比较
amount > 0，先NULLIF(amount, 0)再判断，防止 -0、NaN 等边界值干扰
最易被忽略的是字段语义漂移：比如两个系统都叫 score，一个范围是 0–100，另一个是 0–1.0。视图里不做归一化，上层聚合就会失真。这类问题不会报错，但结果不可信——得靠业务口径文档+定期抽样校验，不能只信 SQL 语法通过。
