什么是SQL视图的列映射冲突及在重构时如何平滑过渡？

视图列映射冲突是语义断裂而非语法错误，因外部代码依赖的列名、类型或顺序被修改导致取错值、报错或返回NULL；重构时须新旧视图并存、渐进切换，并在视图定义中显式重命名JOIN冲突列。

视图列映射冲突不是语法错误，而是查询层的语义断裂：当外部代码依赖的列名、类型或顺序在视图定义中被修改时，调用方会悄无声息地取错值、报错或返回 NULL。

为什么 SELECT * FROM v_user 会突然崩掉

视图本身不存储数据，只保存 SELECT 语句。一旦你重构 v_user，比如删掉 phone 列、把 status 改成 user_status，所有没显式写字段名的调用（尤其是 SELECT * 或 ORM 的 auto-mapping）立刻失效。

• PostgreSQL/SQL Server 直接报错：column "phone" does not exist
• MySQL 可能静默跳过缺失列，导致应用拿到少一列的数据，且无提示
• MyBatis、Django ORM 等按列名绑定结果集，列名对不上就设默认值或抛 MappingException
• BI 工具拖拽字段后缓存了旧列结构，刷新数据时图表空白但日志里没报错

重构视图时如何不中断线上服务

核心原则：新旧视图并存 + 渐进切换，而不是 DROP + CREATE。

• 先建新视图，命名带版本号，如 v_user_v2，定义里确保所有旧列都存在（哪怕用 NULL::text AS phone 填充占位）
• 对外暴露的“主视图”用 CREATE OR REPLACE VIEW v_user AS SELECT * FROM v_user_v2 —— 这步只是改指针，零停机
• 禁止在 v_user_v2 中删除旧列或改类型；若必须删，先用 CASE WHEN FALSE THEN phone END AS phone 保持兼容，等下游全部切到新字段后再清理
• 用 pg_views（PostgreSQL）或 sys.views（SQL Server）查依赖：谁在查 v_user？哪些应用连的是这个视图？别只信文档

列名重复时怎么让 JOIN 查询不翻车

视图内部用了 JOIN，结果集出现两个 id，外部查询再 SELECT * 就必然歧义 —— 这不是视图的问题，是调用方式错了。

• 视图定义里必须重命名冲突列：SELECT u.id AS user_id, o.id AS order_id FROM users u JOIN orders o ...
• 如果视图已上线且列名混乱，临时补救：用子查询包装，如 (SELECT user_id, order_id FROM v_orders_with_users) AS t，再在外层 SELECT 显式取字段
• 绝对不要在视图里留 SELECT * —— 它会让列集合变成黑盒，下次加表就崩
• 检查 ORM 映射文件是否硬编码了列名；如果是 MyBatis 的 <resultMap>，确认 <id column="id"> 指向的是哪个表的 id

最危险的不是改列名，而是以为“只是换个写法”，结果忘了下游有 Shell 脚本用 cut -f3 按字段位置取值，或者 BI 报表里写了 [Column3] 这种位置引用 —— 这类隐式依赖根本不会出现在 SQL 日志里，只能靠全链路扫描和灰度验证。