UNION视图不可更新，因其合并多源结果导致行无法唯一映射到单张基表；MySQL等数据库直接拒绝DML操作，仅Oracle/SQL Server可通过INSTEAD OF触发器实现，但MySQL不支持。
UNION 视图报错 “Cannot update a view that does not derive from a single table”
因为 UNION 合并了多个查询结果集，数据库无法确定 INSERT/UPDATE/DELETE 操作该作用于哪张基表、哪一行。SQL 标准和主流数据库（MySQL、Oracle、SQL Server）都明确禁止对含 UNION 的视图执行 DML —— 它不满足“可更新视图”的最基本前提：单源、无歧义的行映射关系。
UNION 为什么破坏了行到基表的唯一映射
一个视图要支持 UPDATE，必须能将每一行结果精确回溯到基表中某一行（且仅一行）。UNION 会做三件事，全部切断这种映射：
- 去重（即使用了 UNION ALL，语义上仍是“多源拼接”，引擎不保证顺序或归属）
- 列对齐强制类型兼容，可能隐式转换或截断，导致原始值不可逆
- 相同 SELECT 列名来自不同表时，无法区分
id是来自users.id还是admins.id
例如：SELECT id, name FROM users UNION SELECT id, name FROM admins，当执行 UPDATE ... SET name = 'x' WHERE id = 100，数据库根本不知道该改 users 还是 admins 里的记录。
想更新 UNION 视图数据？只能靠 INSTEAD OF 触发器
这是唯一合规路径，但只在 Oracle 和 SQL Server 支持；MySQL 不支持 INSTEAD OF 触发器，所以对 UNION 视图完全只读。
- Oracle 中需先创建视图，再定义
INSTEAD OF INSERT/UPDATE/DELETE触发器，在触发器体内手动写明各分支逻辑 - 触发器里必须显式处理每条语句应影响哪张表、是否校验约束、如何处理冲突（比如两个源表都有 id=100）
- 性能开销显著：每次 DML 都绕过优化器，走 PL/SQL 或 T-SQL 解析，且无法利用基表索引下推
替代方案比硬扛 UNION 视图更实际
多数业务场景下，强行更新 UNION 视图是设计信号异常——说明本不该把异构数据揉进一个逻辑入口。
- 拆成多个单表视图，各自可更新，应用层协调操作
- 用 CTE +
UPDATE ... FROM（SQL Server）或UPDATE ... JOIN（MySQL）替代视图更新逻辑 - 若只是需要“统一查询+分别更新”，直接在应用代码里分 dispatch，比维护触发器更清晰、更易测
真正容易被忽略的是：UNION 视图的不可更新性不是 bug，而是保护机制。一旦绕过（比如用触发器硬写），就等于自己承担了原本由数据库保证的行级一致性责任。
