视图字段应显式列出而非用SELECT *，避免硬编码导致扩展失败；字段稀疏时用UNION ALL分层拆分；嵌套深度限1～2层；新增字段优先垂直拆表+视图聚合。
视图字段硬编码会导致后续扩展失败
直接在 CREATE VIEW 语句里写死所有列名（比如 SELECT id, name, status FROM users），后续只要基表加了新字段，视图就无法自动包含它。业务一提“再加个 last_login_at 字段”，你就得手动改视图定义——这在多个服务共用同一视图时极易漏改、错改，还可能引发下游应用报 Unknown column 错误。
避免方式很简单：明确列出所有当前需要的字段，但不依赖 *；同时把视图的字段边界划清楚——只暴露业务契约字段，不把基表所有列都兜进来。
- 永远不用
SELECT *定义视图，哪怕基表只有 3 列 - 新增字段时，必须同步更新视图定义，并走 SQL 变更评审流程
- 如果视图被多个系统消费，建议用注释标明字段来源，例如
-- 来源: users.last_login_at (2026-10 新增)
用 UNION ALL 拆分逻辑应对字段稀疏场景
当某些字段只存在于部分记录中（比如你知识库提到的“仅 2–3% 用户有商城订单信息”），强行塞进主视图会导致大量 NULL，既浪费网络传输，又让下游解析逻辑复杂化。这时候更适合用 UNION ALL 把“通用字段”和“可选模块字段”拆成两个逻辑层。
例如建一个基础视图 v_user_base，只含 id、name、created_at；再建一个 v_user_with_mall，JOIN 订单扩展表并显式声明所有商城字段。下游按需 SELECT * FROM v_user_base 或 SELECT * FROM v_user_with_mall，互不影响。
- 拆分后，新增商城字段只需改
v_user_with_mall，不影响其他业务查询 -
UNION ALL不去重、不排序，性能开销极低，比反复LEFT JOIN更可控 - 注意两个子查询的列数、类型、顺序必须严格一致，否则
UNION ALL会报错
视图嵌套要控制深度，避免执行计划失控
有人喜欢一层套一层：用 v_orders_summary 基于 v_orders_detail，而后者又基于 v_user_enhanced……三层嵌套后，MySQL 的 EXPLAIN 输出里经常出现 derived 或 materialized 临时表，查询性能断崖下跌。视图本身不存数据，但嵌套过深会让优化器失去对真实数据分布的判断力。
实操中建议：单个视图最多引用 1～2 层其他视图；超过这个深度，直接把底层 SELECT 拷出来重写，哪怕重复几行代码也比维护性差强。
- 用
SHOW CREATE VIEW view_name查看实际展开的 SQL，确认有没有意外的子查询嵌套 - 关键路径上的视图（如报表首页调用的）务必用
EXPLAIN FORMAT=TREE看执行计划，警惕dependent subquery - 如果嵌套不可避免，给最内层视图涉及的字段补上索引——因为优化器往往只敢对基表字段下推条件
字段扩展时优先走“垂直拆分+视图聚合”，而非水平加列
你知识库中提到的 user_all_info 表已有 81 字段，再加 5 个商城字段，不是技术做不到，而是会让整张表越来越难维护：ALTER TABLE 耗时长、备份恢复慢、备份集体积膨胀、ORM 映射容易出错。这时候“加字段”是假捷径，“建新表 + 视图聚合”才是真扩展。
具体做法：新建 user_mall_orders 表存那 5 个字段，用 user_id 关联；然后创建视图 v_user_full，用 LEFT JOIN user_mall_orders ON u.id = m.user_id 把字段拼回去。这样既保持主表稳定，又让商城字段可独立演进。
- 新加字段？只改
user_mall_orders表结构，不影响主表 DDL - 字段要归档？直接删
user_mall_orders表，视图里LEFT JOIN自动返回 NULL，业务无感 - 后续想上物化视图或缓存？聚合逻辑已封装在视图里，替换成本远低于散落在各处的 JOIN
视图不是银弹，它的灵活性恰恰藏在“定义即契约”这个特性里——每次字段变动，你都在重新确认哪些数据该被谁看到、以什么形态看到。越早把字段生命周期和视图边界对齐，后期就越少掉进“改一个字段，测五套系统”的坑。
