视图设计须严格遵循四原则：字段需显式别名防冲突，UNION ALL 各子查询字段顺序与类型必须对齐，业务 WHERE 条件不得写入视图而应下推，MySQL 5.7 等旧版视图不可更新。
视图字段别名必须显式声明，否则会继承原表名导致冲突
多个源表有同名列（比如 id、created_at）时，直接 SELECT * 创建视图会报错或覆盖字段。PostgreSQL 和 SQL Server 会拒绝执行，MySQL 虽允许但后续查询可能取错列。
- 必须为每个字段写
AS别名，例如users.id AS user_id - 命名建议带来源前缀（
user_name、order_name），避免未来加表后重名 - 别名不能含空格或特殊字符，否则后续用 ORM 或 BI 工具容易出错
UNION ALL 合并多表时，字段顺序和类型必须严格一致
用视图统一不同结构的表（如分库日志表、多租户订单表），常靠 UNION ALL 拼接。但只要一行字段顺序错位，或某列是 VARCHAR 另一个是 TEXT，整张视图就查不出数据，甚至不报错只返回空结果集。
- 所有子查询的字段数、顺序、类型要完全对齐；不确定时统一转成
TEXT或JSON类型兜底 - 补全缺失字段用
NULL::TEXT（PostgreSQL）或CAST(NULL AS CHAR)（MySQL），别用裸NULL -
UNION会去重且慢，一律用UNION ALL，去重逻辑交给上层应用处理
视图里别写 WHERE 条件来“过滤业务逻辑”
有人习惯在视图定义里加 WHERE status = 'active'，想着“省得每次查都写”。但这会让视图失去通用性：一旦需要查全部状态，就得建新视图或绕过它，反而增加维护成本。
- 视图只做字段映射、结构对齐、基础脱敏（如
REPLACE(phone, '……', '**')），不承担业务筛选职责 - 真实业务条件一律下推到查询语句中，数据库才能走索引；视图里写死条件等于放弃优化机会
- 如果真要区分场景，建多个轻量视图（
v_orders_active、v_orders_all），比在单个视图里塞 CASE 更清晰
MySQL 8.0+ 才支持可更新视图，旧版本改不了底层表
以为建了视图就能 INSERT INTO v_users SELECT ……？MySQL 5.7 及更早版本对视图的更新支持极弱：含 UNION、聚合、子查询、常量列的视图一律不可更新，连 UPDATE 都报错 ERROR 1393 (HY000): Can not modify more than one base table through a join view。
- 确认 MySQL 版本是否 ≥ 8.0.19，再查官方文档里“Updatable Views”章节的限制清单
- PostgreSQL 视图默认不可更新，需配合
INSTEAD OF触发器；SQL Server 也类似，别假设“建完就能写” - 如果业务真需要写入统一入口，用存储过程或应用层路由更靠谱，别强扭视图
字段别名、类型对齐、条件下沉、版本兼容——这四点漏掉任何一条，视图就会从“统一接口”变成“隐藏坑位”。尤其跨库合并时，连字符集不一致都能让 UNION ALL 返回乱码，这种细节根本不会报错，只能靠查数据才发现。
