视图查询慢需先展开其真实sql：postgresql用pg_get_viewdef、sql server用sp_helptext、mysql查information_schema.views；若执行计划出现materialize、temp table或基表重复扫描，说明内联失败；三层以上嵌套必导致基数估算严重偏差，应拆解为cte或参数化函数。
视图查询慢，先看它到底执行了什么SQL
视图本身不存数据，SELECT * FROM my_view 看起来简单，但背后可能是 5 张表 JOIN + 3 层嵌套子查询。直接查视图得不到真实开销，必须展开——否则你优化的只是“假问题”。
实操建议：
- PostgreSQL：用
pg_get_viewdef('my_view')逐层展开，把所有嵌套视图拼成一条完整 SQL 再分析 - SQL Server：用
sp_helptext 'my_view'查定义，注意检查是否含GETDATE()、NEWID()或OR条件——这些会强制优化器放弃谓词下推 - MySQL：没有原生展开函数，得手动查
information_schema.VIEWS中的VIEW_DEFINITION字段，再逐层替换
执行计划里哪些信号说明视图没被内联
理想情况下，视图会被优化器“内联展开”，等价于手写 JOIN；但一旦出现 MATERIALIZE、Temp Table 或同一张基表被扫描多次，就说明内联失败，反而多了一层物化开销。
实操建议：
- PostgreSQL：
EXPLAIN (ANALYZE, BUFFERS)中关注Rows Removed by Filter占比——若某表过滤掉 95% 行，但Buffers高得离谱，大概率是 WHERE 没下推到基表扫描阶段 - SQL Server：
SET STATISTICS XML ON后看执行计划 XML，搜RelOp LogicalOp="Compute Scalar"或Spool节点，这些是物化中间结果的标志 - MySQL 8.0+：
EXPLAIN FORMAT=TREE里出现-> Materialize或重复出现同一table名，就是嵌套未展开的铁证
为什么加了 WHERE，底层表还在全表扫描
外层写 WHERE user_id = 123，执行计划里订单表仍显示 type: ALL（全表扫描），根本原因不是索引缺失，而是视图定义阻断了条件下推。
常见阻断点：
- 视图里用了
UPPER(name)，外层 WHERE 对name过滤 → 函数包裹列无法走索引 - 视图定义含
SELECT *，外层加ORDER BY created_at LIMIT 10→ 优化器不敢提前裁剪，只能全量物化再排序 - 嵌套视图中某一层用了
TOP 100或OFFSET 100 FETCH NEXT 20→ 基数估算崩溃，优化器放弃下推
验证方法：把视图 SQL 拿出来，手动加上同样 WHERE 条件再 EXPLAIN，对比执行计划差异——如果手写 SQL 走了 ref 而视图走了 ALL，问题就定位在视图结构上。
三层以上嵌套视图，别硬扛，该拆就拆
视图嵌套超过三层后，优化器对中间结果集大小的估算误差常达 100 倍以上，导致连接顺序错乱、驱动表选反、哈希连接退化为嵌套循环——性能断崖下跌不是偶然，是必然。
实操建议：
- 用
pg_stat_statements（PostgreSQL）或sys.dm_exec_query_stats（SQL Server）查该视图的实际logical_reads，如果某次调用突然暴涨 5 倍，大概率触发了最差路径 - 把关键中间层改成 CTE：
WITH order_summary AS (SELECT ...) SELECT ... FROM order_summary JOIN ...——CTE 在多数引擎中默认可内联，且避免了视图的元数据固化问题 - 若某层只被 2~3 个报表复用，直接改用内联表值函数（SQL Server）或参数化 CTE（PostgreSQL），把
@user_id作为输入传进去，比硬套视图靠谱得多
真正难的不是看懂执行计划，而是判断哪一层展开后会让优化器“发懵”。嵌套越深，越要主动打破抽象，回到原始表和索引关系上重新建模。
