视图不能完全挡住 ALTER TABLE，仅对查询侧有限屏蔽；需显式列名、避免 SELECT *、主动维护依赖链，并警惕嵌套与下推失效风险。
视图能挡住 ALTER TABLE 吗？
能，但只挡得住查询侧。只要视图定义里没硬编码字段名、没用 SELECT *，物理表加字段、改字段类型（兼容前提下）、甚至拆分成多表，上层应用查视图完全无感。
关键在「定义稳定」：视图必须显式列出字段，且字段表达式不依赖被删字段或已弃用函数。
- 错误写法：
CREATE VIEW user_summary AS SELECT * FROM users—— 表一加字段，视图输出列就变，下游SELECT COUNT(*)或 ORM 映射可能崩 - 正确写法：
CREATE VIEW user_summary AS SELECT id, name, email, created_at FROM users - 若物理表把
email拆进contacts表，视图可改成JOIN，应用代码照旧
ALTER COLUMN 或 DROP COLUMN 时视图会报错吗？
会，但只在「刷新视图元数据」或「执行查询时」暴露，不是建完就报。PostgreSQL 会惰性检查；MySQL 8.0+ 在查询时才解析依赖；SQL Server 更激进，ALTER TABLE 可能直接拒绝——如果它发现有视图正引用该列。
所以不能靠“建了视图就万事大吉”，得主动维护依赖链。
- 查依赖：PostgreSQL 用
pg_depend或\d+ view_name；SQL Server 用sys.dm_exec_describe_first_result_set - 改字段前先查：
SELECT * FROM pg_views WHERE definition LIKE '%old_column%' - 别用
ALTER VIEW硬修——应先DROP VIEW再CREATE VIEW，避免权限或依赖残留
视图嵌套三层还安全吗？
不安全。每层嵌套都放大解析开销和错误隐蔽性。PostgreSQL 允许嵌套，但查询计划器可能无法下推谓词；SQL Server 对嵌套深度有限制（默认 32，但实际到 5 层以上就难调试）；MySQL 5.7 根本不支持嵌套视图物化。
真正解耦不是靠“套娃”，是靠「单层稳定接口 + 明确所有权」。
- 业务模块 A 只读
v_user_profile，这个视图由模块 A 的 DBA 维护，背后可连users、profiles、settings - 禁止模块 B 的视图去
SELECT * FROM v_user_profile再加工——这等于把解耦层又焊死了 - 性能提示：
EXPLAIN看执行计划，如果出现Subquery Scan套多层，说明优化器放弃下推，索引可能失效
WHERE 条件能下推到视图底层吗？
取决于数据库和视图写法。简单视图（无聚合、无 DISTINCT、无窗口函数）通常能下推；一旦含 GROUP BY 或 ROW_NUMBER()，条件大概率卡在视图层过滤，导致全表扫描。
这不是 bug，是语义限制：你让视图先算出「每个部门最高薪员工」，再加 WHERE dept = 'eng'，数据库不敢把 dept = 'eng' 提前塞进子查询——怕漏掉其他部门的“最高薪”候选。
- 验证方法：
EXPLAIN (VERBOSE) SELECT * FROM v_top_salary WHERE dept = 'eng'，看Filter出现在哪一级 - 救急写法：把常用过滤字段显式透传，比如视图定义里保留
dept，并确保底层表对该字段有索引 - 别信“视图自动优化”，尤其是跨库或联邦查询场景，下推基本失效
最常被忽略的点：视图没有事务边界，也没有缓存生命周期。你以为封装了一层就稳了，其实 SELECT 还是直打物理表——锁、阻塞、统计信息过期，一个不少。解耦的是逻辑，不是运行时。
