视图嵌套超过3层时性能必然失控，优化器放弃代价估算、条件下推失效、执行计划随机漂移；必须人工逐层展开（如pg用pg_get_viewdef、sql server用sp_helptext、mysql用show create view）获取真实sql并用explain analyze验证条件下推，或满足硬性条件后建物化视图。
视图嵌套超过3层时，关联性能问题基本已不可修复——不是“可能变慢”，而是优化器主动放弃代价估算，条件下推失效，执行计划随机漂移。必须人工展开或物化，没有中间路线。
怎么手动展开嵌套视图查真实SQL
别信 SELECT * FROM v_a 看起来快，那只是幻觉。真正要跑的是它层层展开后的完整SQL。你得把所有嵌套一层层剥开，拼出最终等价语句再分析。
- PostgreSQL：用
pg_get_viewdef('v_a')查 v_a 定义；若它引用v_b，再跑pg_get_viewdef('v_b')，直到触底基表 - SQL Server：用
sp_helptext 'v_a'，注意它不递归，得手动追v_b、v_c - MySQL：
SHOW CREATE VIEW v_a，但5.7及以前不支持视图合并，展开后还得验证是否真被内联 - 关键动作：把最终拼出的SQL粘进
EXPLAIN (ANALYZE, BUFFERS)（PG）或“包含实际执行计划”（SSMS），重点看 WHERE 条件有没有下推到最内层扫描节点
哪些情况必须建物化视图而不是硬展开
展开能看清问题，但不能解决所有问题。当底层基表更新极慢、而上层查询又高频重复消费同一中间结果时，物化才是正解——但得满足硬性条件，否则反而更慢。
- PostgreSQL：只有
CREATE MATERIALIZED VIEW支持并发刷新，但要求基表有主键或唯一约束，且不能含 volatile 函数（如NOW()、RANDOM()） - SQL Server：必须用
CREATE VIEW ... WITH SCHEMABINDING+CREATE UNIQUE CLUSTERED INDEX，且定义中禁用GETDATE()、子查询、SELECT * - MySQL：无原生物化视图，只能靠
CREATE TABLE tmp AS SELECT ...+ 定时TRUNCATE/INSERT，记得给tmp表的关键字段加索引 - 判断依据：用
EXPLAIN (ANALYZE, BUFFERS)对比物化前后逻辑读（Shared Hit Blocks），下降 ≥70% 才值得
展开后发现 JOIN 条件没走索引怎么办
展开只是第一步，常见陷阱是：明明写了 ON u.id = o.user_id，但执行计划里还是 type=ALL。根本原因往往不在视图结构，而在字段表达式或隐式转换。
- 检查 JOIN 字段是否被函数包裹，比如
ON UPPER(u.name) = UPPER(o.name)—— 这会让两边都全表计算，索引彻底失效 - 确认字段类型严格一致：
users.id是INT，orders.user_id不能是BIGINT或VARCHAR，否则触发隐式转换 - 查看执行计划中
rows估算值是否爆炸（比如从100跳到100万），这是谓词未下推的铁证 - 临时补救：在基表上建覆盖索引，例如
CREATE INDEX idx_orders_user_status ON orders(user_id) WHERE status = 'active'（PG partial index）
嵌套视图的调用链一旦超过三层，依赖关系就基本不可信。哪怕 sp_depends 或 pg_depend 显示“无依赖”，也得人工逐层核对字段来源和过滤位置——因为优化器早已不把它当一回事了。
