sql视图ddl脚本不能直接丢进git，因视图仅存于数据库，git中脚本若与库状态脱节（如字段改名、依赖表被删），ci执行时会报“relation/column does not exist”；需拆分为依赖校验与变更执行两步，通过information_schema查询校验引用对象，并在ci中用select * from view limit 0做运行前验证。
SQL视图DDL脚本为什么不能直接丢进Git？
因为视图本身不存于Git，只存于数据库；你提交的 CREATE VIEW 脚本一旦和目标库状态脱节（比如字段改名、依赖表被删），CI流水线执行时就会报错 ERROR: relation "xxx" does not exist 或 column "yyy" does not exist。Git里存的是“意图”，不是“快照”——必须让每次部署前能验证这个意图是否仍可兑现。
如何让视图脚本在CI中安全执行？
核心是把“建视图”拆成两步：先校验依赖，再执行变更。不能无脑 DROP VIEW IF EXISTS + CREATE VIEW，尤其在线上环境。
- 用
pg_get_viewdef()（PostgreSQL）或SHOW CREATE VIEW（MySQL）导出现网视图定义，与Git中脚本做 diff，识别是否真有变更 - 对新增视图，检查其
SELECT中所有引用的表/列是否存在且类型兼容（可用information_schema.columns查询校验） - CI阶段加一道脚本：运行
psql -c "SELECT * FROM my_new_view LIMIT 0;"，仅语法+依赖校验，不查数据——失败即阻断发布 - 避免在脚本里写硬编码 schema 名，统一用变量
${DB_SCHEMA}，通过CI环境变量注入
Git分支策略怎么匹配视图生命周期？
视图不是独立服务，它依附于底层表结构。所以分支模型要对齐表变更节奏：
-
main分支对应生产库结构，其视图脚本必须能 100% 在生产库psql -f view_v1.sql成功执行 - 新功能分支修改了表结构？那它的视图脚本必须和表迁移脚本放在同一 PR，并在 CI 中联动测试（例如先跑
ALTER TABLE，再跑视图校验） - 禁止在
feature/*分支里维护“未来才上线”的视图脚本——它会污染main的一致性，也增加 merge conflict 概率
为什么 pg_dump --schema-only 不适合管理视图版本？
因为 pg_dump --schema-only 输出的是当前库全量对象定义，包含顺序依赖、权限语句、注释等噪音，无法体现“本次迭代变更点”。它适合灾备，不适合 CI。
- 真正要进 Git 的，是人工编写的、最小化的
CREATE OR REPLACE VIEW xxx AS SELECT ...文件，路径按业务域组织，如/views/analytics/revenue_summary.sql - 自动生成工具（如
pgsync或自研脚本）只用于比对：把线上视图 dump 出来，和 Git 版本 diff，报警不一致，但不自动覆盖 - 权限控制（
GRANT SELECT ON xxx TO analyst_role）必须单独成文件，和 DDL 分离——权限变更频率低，且需审批，混在一起会导致每次 DDL 更新都误触权限重置
实际落地最常被跳过的环节，是视图依赖的“跨库引用”校验——比如视图里写了 other_db.public.users，而 CI 流水线连的只是本库。这种错误不会在语法检查暴露，只有运行时炸。得在 CI 阶段显式连接目标库并查 pg_foreign_server 或 information_schema.schemata 确认远端库可达。
