能，但需注意数据库兼容性：PostgreSQL、SQL Server、Oracle 支持 SELECT 列表和 FROM 子句中的子查询；MySQL 5.7 及更早不支持 FROM 中子查询，8.0+ 已修复。
SQL 视图里能不能直接写子查询？
能，但得看数据库类型。PostgreSQL、SQL Server、Oracle 都支持在 SELECT 列表或 FROM 子句中直接嵌套子查询；MySQL 5.7 及更早版本不支持 FROM 中的子查询（会报 ERROR 1349 (HY000): View's SELECT contains a subquery in the FROM clause），8.0+ 已修复。
常见错误是把视图当临时表用，以为“只要语法通就能建”，结果在 MySQL 旧版本或某些 ORM 自动推导 schema 时崩掉。
- MySQL 5.7 建视图时若含
(SELECT ……)作为FROM的一部分，直接失败 - PostgreSQL 允许
SELECT id, (SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id) AS log_count FROM users u这种标量子查询 - SQL Server 对相关子查询支持较好，但若子查询引用外部视图字段又没加别名，可能触发
Invalid column name
怎么让嵌套子查询在视图里更稳？
核心原则：把子查询“扁平化”成可复用的结构，而不是堆逻辑。不是不能写，而是写法决定维护成本和执行计划是否可控。
- 优先用
LEFT JOIN替代标量子查询，尤其当子查询要聚合多行时（如COUNT、SUM）——避免对主表每行都触发一次子查询执行 - 如果必须用子查询，确保它不依赖外部列做非关联条件（比如
WHERE x > (SELECT MAX(y) FROM t)是安全的；WHERE x > (SELECT y FROM t WHERE t.id = u.id)是关联的，但需确认索引覆盖t.id） - 在 PostgreSQL 中，可考虑用
LATERAL替代复杂相关子查询，语义更清晰且优化器更容易生成合理计划
视图里子查询影响性能吗？
影响很大，而且往往比你想象的更隐蔽。视图本身不存储数据，每次查询都会展开，子查询也会被重算 —— 即使它看起来只查一次。
- 标量子查询（括号包着的单值
SELECT）在主表每行都会执行一遍，没索引的话就是 N × M 次扫描 -
FROM中的子查询（派生表）通常会被优化器尝试合并，但一旦含GROUP BY、DISTINCT或窗口函数，就大概率固化为物化中间结果，内存 / 临时磁盘压力陡增 - 在 SQL Server 中，若子查询含
TOP或OFFSET/FETCH，视图可能无法被索引视图（indexed view）引用
什么场景下该忍住不用子查询？
当你发现子查询只是为了“先算一个中间值再参与主逻辑”，大概率有更干净的替代方式。真正需要子查询的视图，通常是封装不可拆分的业务规则，比如权限过滤、状态映射。
- 想实现“每个用户最新一条订单”，别写
(SELECT * FROM orders o2 WHERE o2.user_id = u.id ORDER BY created_at DESC LIMIT 1)，改用ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)窗口函数 + 外层过滤 - 想统计“部门平均薪资高于公司平均的员工”，别嵌两层子查询算公司均值，先用 CTE 提前算好，再 JOIN —— 视图虽不支持 CTE，但你可以把 CTE 逻辑提成另一个视图
- ORM（如 Django ORM、SQLAlchemy）读取视图时，常会自动加
SELECT *和隐式排序，若视图里子查询依赖ORDER BY但没配LIMIT，可能触发全表扫描 + 排序溢出
最麻烦的不是语法报错，而是视图建得出来、查得慢、换环境就失效——尤其是跨数据库迁移或升级小版本时，子查询的解析行为可能静默变化。
