内联视图必须作为派生表出现在FROM子句中并带别名，不可用于WHERE；需严格匹配内外层GROUP BY以保证语义正确，推荐用CTE替代深层嵌套，且不支持传参。
内联视图必须写在FROM子句里，不能当WHERE条件用
内联视图本质是派生表（derived table），只能作为FROM子句中的一个“临时表”参与JOIN或直接SELECT。常见错误是把它错放在WHERE里，比如：WHERE salary > (SELECT AVG(salary) FROM employees)——这仍是标量子查询，不是内联视图。
真正内联视图的写法必须带别名并出现在FROM中：
SELECT d.department_name, t.avg_sal FROM departments d JOIN (SELECT department_id, AVG(salary) avg_sal FROM employees GROUP BY department_id) t ON d.department_id = t.department_id;
- 括号包裹的
SELECT必须有别名（如t），否则报ORA-00904: "invalid identifier" - 内层
GROUP BY不能漏，否则AVG()会聚合全表，导致结果行数坍缩为1行 - 外层
SELECT若含非聚合列（如d.department_name），而没在GROUP BY中声明，会触发ORA-00979: not a GROUP BY expression
标量子查询改内联视图时，LEFT JOIN比INNER JOIN更安全
原始标量子查询返回NULL是常态（比如某部门没员工），但直接JOIN会丢行。用LEFT JOIN才能保主表完整性。
示例：把(SELECT MAX(e.salary) FROM emp e WHERE e.deptno = d.deptno)改成内联视图：
SELECT d.deptno, d.dname, t.max_sal FROM dept d LEFT JOIN (SELECT deptno, MAX(salary) max_sal FROM emp GROUP BY deptno) t ON d.deptno = t.deptno;
- 必须用
LEFT JOIN，否则dept中无员工的部门会被过滤掉 - 内层
GROUP BY deptno必须存在，否则MAX(salary)会算全表最大值，所有部门都得到同一个数字 - 别在内层
SELECT里写NVL(MAX(salary), 0)——这会让空部门返回0，而原标量子查询返回NULL，语义不一致
内联视图嵌套过深会导致解析慢、执行计划不可读
Oracle 19c对内联视图嵌套层级没有硬限制，但超过2层后，EXPLAIN PLAN输出会迅速膨胀，且优化器可能放弃某些转换（如谓词下推）。
例如三层嵌套：
SELECT x.name FROM (SELECT * FROM (SELECT * FROM employees) y) x WHERE x.salary > 5000;
- 这种写法等价于直接查
employees，纯属冗余，徒增解析开销 - 如果内层含
ORDER BY或ROWNUM，还可能引发ORA-00904或逻辑错误（因排序在派生表中不保证生效） - 替代方案：用CTE（
WITH子句）分步命名，既保持逻辑清晰，又避免语法嵌套
内联视图无法传参，动态条件得靠外部绑定变量驱动
内联视图是静态SQL结构，不支持像函数那样接收:dept_id参数。想让它“按需过滤”，只能把条件提到外层。
错误写法（语法不通过）：
(SELECT * FROM emp WHERE deptno = :dept_id) t
正确做法是把条件留在外层JOIN或WHERE：
SELECT d.name, t.cnt FROM departments d JOIN (SELECT deptno, COUNT(*) cnt FROM emp GROUP BY deptno) t ON d.deptno = t.deptno WHERE d.location = 'NEW YORK';
- 内层只做聚合/关联准备，不承担业务筛选职责
- 若需多条件动态组合，优先考虑SQL Macro（Oracle 19.7+），它能生成参数化内联SQL片段，而非硬编码视图
- 建物化视图（
MATERIALIZED VIEW）虽可预计算，但刷新延迟和维护成本高，不适合实时性要求高的场景
实际用内联视图时，最容易被忽略的是内外层GROUP BY的一致性：内层漏GROUP BY，结果错；外层漏GROUP BY，报错；两者字段不匹配，结果乱。这不是语法问题，而是数据语义断层。
