会，子查询在视图中每次调用都会重新执行，尤其含GROUP BY、ORDER BY时更慢；MySQL 5.7+默认TEMPTABLE算法，PostgreSQL普通视图无法谓词下推，SQL Server多层嵌套易退化；标量子查询和关联子查询（有索引）较安全，窗口函数、LIMIT、NOW()等则风险高。
视图里用子查询会变慢吗？
会，而且可能比你想象中更慢——尤其是子查询里带 GROUP BY 或 ORDER BY 时。数据库在创建视图时并不执行子查询，但每次查视图，子查询都会重新跑一遍；如果子查询本身要扫大表、做聚合，那调用视图的语句就等于自带一个隐藏性能瓶颈。
- MySQL 5.7+ 对含子查询的视图默认走
TEMPTABLE算法，意味着每次查询都物化成临时表，内存/磁盘开销明显 - PostgreSQL 虽支持
MATERIALIZED VIEW，但普通视图仍按需执行子查询，且无法下推谓词（比如你在外部加WHERE id = 123，子查询内部通常不会提前过滤） - SQL Server 的视图可以内联展开（
NOEXPAND提示除外），但嵌套多层子查询后优化器容易放弃内联，退化为独立执行
哪些子查询能安全放进视图？
核心看两点：是否可被优化器“拍平”，以及是否引入非确定性逻辑。简单标量子查询（返回单值）和关联子查询（EXISTS / IN 形式且关联字段有索引）相对稳妥；但带窗口函数、LIMIT/TOP、用户变量或 NOW() 这类运行时依赖的，进视图就是埋雷。
-
SELECT id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_cnt FROM users u—— 可接受，但注意orders.user_id必须有索引，否则变成 N×M 扫描 -
SELECT *, (SELECT MAX(created_at) FROM logs) AS last_log FROM events—— 危险：标量子查询无关联，每次查视图都全表扫logs SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY score DESC) rn FROM students) t WHERE rn —— 视图里不能直接用，因为 <code>ROW_NUMBER()+WHERE无法下推，实际执行是先算全量再截断
MySQL 视图报 “This view has no definer” 或 “View’s SELECT contains a subquery in the FROM clause” 怎么办？
前者是权限问题：创建视图时没指定 DEFINER，后续用户调用时按当前用户权限检查，容易失败；后者是 MySQL 5.7 以前的硬限制——老版本不支持 FROM 里的子查询（即派生表），必须升级或改写。
- 建视图时显式加
DEFINER = 'admin'@'%'，并确保该用户有足够权限（至少对子查询涉及的所有表有SELECT） - MySQL 5.6 及更早版本遇到
FROM (SELECT ...)报错，只能拆成两层视图，或把子查询逻辑移到应用层预计算 - 用
SHOW CREATE VIEW view_name检查实际定义，注意某些客户端（如 phpMyAdmin）会自动补DEFINER，但脚本部署时可能漏掉
想让视图快一点，绕不开的三个动作
别指望优化器替你兜底。子查询一旦进视图，就失去很多优化机会，得手动干预。
- 给子查询里所有
WHERE和JOIN字段建联合索引，尤其注意外层视图条件能否命中索引最左前缀 - 用
EXPLAIN对着视图查一次，重点看type是否出现ALL、rows是否远超预期、有没有Using temporary或Using filesort - 真有性能压力，优先考虑用物化方式替代：PostgreSQL 建
MATERIALIZED VIEW并定时刷新；MySQL 用定时任务写入中间表，再让视图查这张表
子查询塞进视图看起来省事，但它的执行时机、作用域和优化边界都比想象中模糊。越是觉得“这里写个子查询挺自然”的地方，越要先 EXPLAIN 一把——不然上线后慢，很难定位到是视图里的某层子查询在拖后腿。
