SQL视图无法直接灰度发布，需通过版本化视图名（如user_summary_v1/v2）+应用配置路由实现；禁止DROP/CREATE切换，须校验结构兼容性、避免SELECT*及跨schema引用，并警惕嵌套视图的隐式类型转换风险。
SQL 视图不能直接灰度发布，必须靠应用层或数据库层间接实现
视图本身是只读的逻辑定义，没有“发布状态”概念，数据库不支持 CREATE OR REPLACE VIEW IF NOT EXISTS ... WITH DRAFT = true 这类语法。所谓“灰度发布”，本质是让新旧视图定义在一段时间内共存，并由上游（应用、中间件、调度任务）按需路由到不同版本。强行用 DROP VIEW + CREATE VIEW 切换，会引发查询失败或元数据抖动。
用带版本后缀的视图名 + 应用配置切换是最稳妥的方案
核心思路：不改视图名语义，而是把版本信息显式编码进名称，靠配置控制调用哪个版本。比如原视图叫 user_summary，灰度期同时存在 user_summary_v1 和 user_summary_v2。
- 应用配置里统一管理视图别名映射，例如 YAML 中写
view_alias: user_summary_v2，代码里拼 SQL 时用该变量替代硬编码名 - 上线前先
CREATE VIEW user_summary_v2 AS ...，确认无语法错误、执行计划合理、结果集结构兼容（列名/类型/空值行为） - 灰度期间可并行查
user_summary_v1和user_summary_v2做结果比对，用EXCEPT或简单 COUNT+SUM 校验 - 禁止在视图定义里用
SELECT *，否则v2新增字段会导致v1查询意外多出列，下游解析失败
用同名视图 + schema 切换实现“逻辑灰度”，但有权限和连接池风险
某些数据库（如 PostgreSQL、Snowflake）支持多 schema，可把 v1 放 prod_schema，v2 放 staging_schema，再通过 SET search_path = staging_schema, prod_schema 控制优先级。但这依赖连接粒度控制，容易踩坑：
- 连接池复用时，
search_path可能残留，导致后续请求误走旧 schema - 应用若没显式设
search_path，且默认 schema 是public，那SELECT * FROM user_summary会走到第一个匹配的 schema，行为不可控 - MySQL 不支持
search_path，只能靠database_name.view_name全限定名，但要求应用层动态拼库名，改造成本高
双重定义陷阱：视图嵌套引用时，底层变更会穿透影响上层
如果 user_summary_v2 依赖了 base_events_v2，而 base_events_v2 又依赖 raw_logs，那只要 raw_logs 结构微调（比如某列从 TEXT 改成 JSONB），就可能让 user_summary_v2 的 CASE WHEN 表达式报类型不匹配错误——即使你没动过它自己的定义。
- 每次更新任一底层视图，都得全链路跑一遍
SELECT COUNT(*) FROM view_name+SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'view_name' - 避免跨 schema 引用，尤其不要在
staging_schema的视图里直接引用prod_schema.table，否则灰度失效 - PostgreSQL 中可用
pg_get_viewdef('view_name')提取定义做 diff，但注意它不展开嵌套视图，得递归解析
真正麻烦的不是建两个视图，而是保证它们在整个数据血缘里不互相污染；很多团队卡在第三层嵌套视图的隐式类型转换上，查半天才发现是上游某个 COALESCE(a::text, b::varchar) 在 v2 里因 b 类型变了突然报错。
