内联视图能减少上下文切换，因其使优化器将整个查询重写为单次集合操作，仅需一次解析、一次执行计划生成和一次全量数据拉取，避免外层每行触发独立子查询执行。
嵌套查询本身不直接引发上下文切换，真正导致上下文切换激增的，是那些被错误实现为“循环中反复执行子查询”的逻辑——比如在应用层用 for 循环调用 N 次含子查询的 SQL，或在 PL/SQL/存储过程中用显式游标逐行 FETCH 后再对每行执行一次子查询。
为什么内联视图能减少上下文切换
内联视图（即 FROM (SELECT ...) 形式的子查询）让优化器有机会将整个查询重写为单次集合操作。数据库引擎只需一次解析、一次执行计划生成、一次全量数据拉取，而不是把外层每行都当作触发点去重复调用 SQL 引擎。
- 对比场景：若外层有 10,000 行，而子查询写成
WHERE id IN (SELECT x FROM t2 WHERE t2.ref = t1.id)，且未被优化器自动展开，则可能退化为 10,000 次独立子查询执行 - 内联视图强制物化中间结果，避免重复计算关联逻辑；尤其当子查询含
GROUP BY或LIMIT时，WITH或内联视图比相关子查询更可控 - MySQL 8.0+ 和 PostgreSQL 默认会对简单
IN子查询做 semi-join 转换，但一旦子查询里出现函数、ORDER BY或聚合，转换就失效——此时手写内联视图反而更可靠
什么时候该用内联视图而不是 WITH 或临时表
内联视图适合轻量、一次性、逻辑清晰的中间集抽象；它不落盘、不建对象、无事务开销，但也不支持多次引用。选型关键看是否满足以下条件：
- 子查询结果集不大（通常
- 不需要索引加速（内联视图无法对其字段单独建索引）
- 不想引入额外 DDL（如
CREATE TEMPORARY TABLE）或会话级对象管理成本 - 在 MySQL 中，若子查询含
ORDER BY ... LIMIT，必须包在内联视图里才能保证排序生效（否则LIMIT可能被忽略）
常见踩坑：内联视图没减少开销的典型原因
写了内联视图却没见效，大概率不是语法问题，而是执行路径没走对。重点检查这几处：
-
EXPLAIN显示 type = ALL 或 rows_examined 远大于预期：说明内联视图里的SELECT缺少有效索引，导致物化过程本身就很慢 - 内联视图里用了
UPPER(name)或DATE(created_at)等函数——这会让底层扫描无法走索引，物化代价翻倍 - 外层
WHERE条件没下推到内联视图内部，比如写成SELECT * FROM (SELECT a,b FROM t) v WHERE b > 100，而本可写成SELECT * FROM (SELECT a,b FROM t WHERE b > 100) v - 在 Oracle 中误用
/*+ MATERIALIZE */提示，但目标子查询太小（
真正要砍掉上下文切换，核心不是“用不用内联视图”，而是确保整个查询路径是一次性进入 SQL 引擎、一次性完成计算、一次性返回结果——任何中间环节的行级控制流（FETCH、循环、回调函数），都是切换温床。
