视图连接物理表时执行计划变差，因数据库会内联展开视图为嵌套sql，导致优化器误判连接顺序、索引失效、行数估算失真；含group by/distinct、left join后加where、计算列等进一步加剧问题。
视图连接物理表时，执行计划为什么突然变差
因为视图不是真实表，数据库会在执行前把它“内联展开”成原始SELECT语句，再和物理表一起优化。这意味着：你写的 SELECT * FROM v_customer_orders JOIN orders o ON ... 实际会被重写为 SELECT * FROM (SELECT c.name, COUNT(o2.id) ... FROM customers c LEFT JOIN orders o2 ...) JOIN orders o ON ... —— 两层嵌套 + 多表JOIN，优化器很容易选错连接顺序或放弃使用索引。
常见现象包括：执行计划里出现 Hash Join 替代 Nested Loop、Index Scan 变成 Seq Scan、估算行数爆炸（比如从100行跳到100万），甚至触发临时表 spill 到磁盘。
- 视图定义里含
GROUP BY或DISTINCT，会导致内联后无法下推谓词（WHERE 条件进不去子查询） - 视图用了
LEFT JOIN，而你后续又对右表字段加了WHERE过滤，实际等价于INNER JOIN，但优化器未必能自动转换 - 视图字段是计算列（如
UPPER(name)），连接时用该字段做ON，直接破坏 SARGability
如何让视图+表连接走索引 Seek 而不是 Scan
关键不是“怎么写视图”，而是“怎么让优化器相信它能安全下推条件”。必须确保连接字段和过滤字段在视图展开后仍保持可索引访问的形态。
- 视图定义中避免对索引列做任何函数包装，例如不要写
WHERE UPPER(status) = 'ACTIVE'；如果业务真要忽略大小写，改用带函数的索引（如 PostgreSQL 的CREATE INDEX ON t ((UPPER(status)))）或在应用层统一转大写 - 连接字段必须是基表原生列，不能是
COALESCE(col, 'N/A')或CASE WHEN表达式，否则ON v.id = t.id无法命中t.id上的索引 - 在查询视图时，把能下推的过滤条件显式写在最外层 WHERE，而不是依赖视图内部的 WHERE —— 比如视图定义含
WHERE created_date > SYSDATE-30，但你查的是最近7天，那就额外加AND created_date >= SYSDATE-7，帮助优化器缩小驱动表范围
物化视图替代普通视图是否就能解决连接性能问题
不一定。物化视图（MATERIALIZED VIEW）本质是物理表，连接时不会被展开，这点确实有利；但它引入了新约束：刷新策略、日志开销、数据延迟风险。
- 若用
ON COMMIT刷新，每次更新基表都同步刷物化视图，写入性能可能下降50%以上，尤其涉及多表 JOIN 的物化视图 - 若用
FAST刷新，必须提前建好物化视图日志，并满足严格条件（如 SELECT 列含基表ROWID、无不可重写函数），否则退化为完全刷新，更慢 - 物化视图上没索引，等于裸表连接 —— 别忘了手动建索引，尤其是连接字段和常用 WHERE 字段
- Oracle 中启用
ENABLE QUERY REWRITE后，原SQL才可能被重定向到物化视图；但若你显式写了JOIN v_mv ON ...，就绕过了重写机制，还是查原表
什么时候该放弃视图，改用临时表或CTE
当视图逻辑固定、调用频繁、且连接对象稳定时，硬编码反而更可控。视图的价值在于复用和抽象，不是性能兜底方案。
- 临时表（
CREATE TEMP TABLE）适合中间结果集较大（>1万行）、需多次引用、且连接字段能建索引的场景；比视图多一次 I/O，但换来确定的执行路径 - CTE（
WITH子句）在 PostgreSQL / SQL Server 中可被物化（取决于版本和MATERIALIZE提示），但在 Oracle 中默认不物化，只是语法糖，慎用于大结果集 - 如果视图只被一个业务模块高频调用，直接把视图 SQL 拆出来，用参数化查询 + 合理的
OPTION (RECOMPILE)（SQL Server）或绑定变量提示（Oracle），往往比维护一个通用视图更高效
最常被忽略的一点：视图嵌套层级超过2层后，执行计划几乎不可预测。与其花时间调优嵌套视图的连接，不如把核心聚合逻辑下沉到物化视图或预计算表，让上层查询真正变成“单表 JOIN”。
