MySQL 5.7 及更早版本不支持在视图中裸写 UNION，必须用括号包裹并加别名作为派生表，否则报错 ERROR 1349；本质是解析器要求 UNION 必须位于 FROM 子句中，而非顶层 SELECT。
MySQL 5.7 及更早版本不支持直接在视图定义中使用 UNION（或 UNION ALL），错误提示为 ERROR 1349 (HY000): View's SELECT contains a subquery in the FROM clause。这不是权限或语法写错，而是内核限制——必须用嵌套子查询包装，不能“裸写” UNION。
为什么裸写 UNION 在 CREATE VIEW 中会报错
MySQL 把 UNION 视为一种复合查询结构，要求它必须出现在 FROM 子句中作为派生表（derived table），而不能直接作为视图顶层的 SELECT 主体。即使语义上等价，5.7 及之前版本的解析器会拒绝这种写法。
- 报错语句示例：
CREATE VIEW v_users AS SELECT xh FROM t1 UNION SELECT zgh FROM t2; - 本质不是“不支持 UNION”，而是“不支持未包裹的 UNION”
- MySQL 8.0.19+ 已放宽该限制，但生产环境仍大量使用 5.7/8.0.1x，不能依赖版本升级解决
必须用子查询嵌套：正确写法与关键细节
把整个 UNION ALL 查询用括号包起来，并起别名，再从这个派生表中 SELECT * —— 这是唯一兼容所有旧版本的方案。
- 正确示例：
CREATE VIEW v_users AS SELECT * FROM (SELECT xh AS id, xm AS name FROM t_wpsbmhyhqltb_bzksjbxx WHERE sfzx='是' UNION ALL SELECT zgh AS id, xm AS name FROM t_wpsbmhyhqltb_jzgjbxx WHERE rylb='在职人员') AS t; -
AS t别名不可省略，否则报错Every derived table must have its own alias - 列别名（如
xh AS id）建议显式声明，避免字段名冲突或顺序错乱 - 如果原
UNION各分支列数/类型不一致，必须提前对齐（见下一条）
UNION ALL 字段对齐失败的典型表现与修复
即使嵌套了子查询，仍可能报错：列数不等、字符集混用（#1271 Illegal mix of collations）、数值与字符串类型冲突。这些不是视图专属问题，但在嵌套后更容易被忽略。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 列数不匹配：两个
SELECT分支返回列数不同 → 在少列分支补NULL AS colname或占位值 - 字符集冲突：比如一个表用
utf8mb4_unicode_ci，另一个用utf8mb4_general_ci→ 统一用CONVERT(col USING utf8mb4)或建表时就规范字符集 - 数据类型强转需求：如
id在一张表是INT，另一张是VARCHAR→ 显式CAST(id AS CHAR)或CAST(id AS SIGNED) - 别名优先于原始字段名：子查询内用
AS定义的列名，才是外部SELECT *看到的名字
临时表方案为何通常不实用
虽然知识库提到“用 CREATE TEMPORARY TABLE + 视图引用”可行，但它在真实场景中几乎不可行：
- 临时表只对当前会话可见，视图被其他会话调用时查不到该表 → 直接报
Table doesn't exist - 若改用普通表，则需额外维护生命周期、并发写入、权限控制，失去视图“轻量封装”的意义
- 每次数据变更都要手动
TRUNCATE + INSERT ... SELECT ... UNION，违背视图实时性初衷 - 只有极少数离线报表且能接受定时刷新的场景才考虑此路
真正需要关注的是子查询嵌套的写法稳定性——它不依赖 MySQL 版本升级，不引入额外对象，也不破坏事务一致性。容易被忽略的是：嵌套层里的每个 SELECT 都要独立满足 SQL 语法和类型规则，而不是只看最外层。
