如何通过视图扁平化策略有效缓解SQL查询中嵌套过多视图的性能瓶颈？

本文共计1037个文字，预计阅读时间需要5分钟。

图嵌入多层超三层的，性能大概已失控，不是‘可能慢’，而是‘必然不可控’——优化器放弃代价估算、条件下推失效、执行计划随机漂移，这是结构性问题，不是加个索引能救的。

为什么嵌套视图会让EXPLAIN看起来“没问题”但实际极慢

你跑 EXPLAIN ANALYZE 看到的可能是“Seq Scan on orders”，但没告诉你这行扫描是发生在最内层视图 v_region_map 还是外层 v_orders_summary；更关键的是，如果外层加了 WHERE country = 'CN'，而执行计划里这条件根本没下推到 regions 表的扫描节点，说明优化器已放弃重写整个嵌套链。常见现象包括：

• 估算行数从 100 跳到 1000000（爆炸式增长）
• 出现未预期的 Materialize 节点，且耗时占总时间 70%+
• 同一查询在不同时间生成完全不同的执行计划（比如有时走 Nested Loop，有时变 Hash Join）

用CTE替代嵌套视图时，哪些写法会适得其反

CTE 不是万能扁平化工具，错误用法反而加重负担。PostgreSQL 默认可能将 CTE 当作物化步骤强制执行，而原视图嵌套反而支持条件下推。