视图嵌套子查询本身不慢，慢的是数据库被迫重复执行、无法下推条件或无法合并逻辑；尤其嵌套超三层时，MySQL 5.7及以前放弃优化，SQL Server与PostgreSQL易选错连接顺序。
视图里嵌套子查询本身不慢，慢的是数据库被迫重复执行、无法下推条件、或根本没法合并视图逻辑——尤其当嵌套超过三层时，MySQL 5.7 及以前直接放弃优化，SQL Server 和 PostgreSQL 也常选错连接顺序。
为什么视图嵌套子查询后 EXPLAIN 显示 rows 暴涨
根本不是“写法丑”，而是优化器在多层包装下丢失了关键信息：
- 外层
WHERE user_id = 123无法穿透到内层子查询，导致先全量计算视图再过滤 - 子查询中用了
SELECT *或别名冲突（如两个COUNT(*) AS total），视图建表失败或列序错位，后续 JOIN 全乱 - MySQL 5.7 前默认禁用视图合并（
merge），哪怕你只查一个字段，也会完整跑完所有子查询逻辑
哪些子查询必须从视图里拆出来改写成 JOIN
只要视图定义里出现以下任一模式，性能大概率已受损，优先重构成显式 JOIN：
-
WHERE ... IN (SELECT ...)—— 尤其内层还带聚合或多表 JOIN，易触发 N² 扫描 -
NOT IN (SELECT ...)或NOT EXISTS嵌套两层以上，应转为LEFT JOIN ... WHERE right_table.id IS NULL - 同一张大表在视图里被多个子查询反复扫描（如两次
SELECT COUNT(*) FROM orders WHERE status = 'paid'）
例如原视图：CREATE VIEW v_inactive_users AS SELECT u.user_id FROM users u WHERE u.user_id NOT IN (SELECT l.user_id FROM user_logins l WHERE l.login_time > DATE_SUB(NOW(), INTERVAL 30 DAY))；应改为 LEFT JOIN 形式，让优化器有机会走索引嵌套循环。
什么时候可以用 CTE 替代深层嵌套，什么时候反而更慢
WITH 不是“语法糖”，它只有在满足明确条件时才真正提升效率：
- 必须用：
WITH中间结果被引用 ≥2 次（如既用于JOIN又用于WHERE EXISTS），或需传参（如@start_date） - 禁用：
WITH t AS (SELECT * FROM orders WHERE created_at > '2024-01-01')这种只用一次、无聚合、无复用的写法，纯属增加解析开销 - MySQL 8.0.23+ 可加
MATERIALIZED强制物化，但若中间结果没索引，物化后 JOIN 仍可能全表扫
CTE 内必须显式声明字段名，SELECT * 在跨版本迁移时极易因底层表加列导致字段错位——这不是警告，是线上翻车高频点。
视图权限与列名冲突：上线前最容易忽略的两个硬伤
性能问题往往卡在部署环节，而非执行环节：
- 视图定义里查了
orders表，但调用者没SELECT权限 → 直接报ERROR 1142 (42000): SELECT command denied - 子查询里写了
SELECT a.id, b.id，建视图时报ERROR 1059 (42000): Identifier name 'id' is too long，必须手动写成a.id AS a_id, b.id AS b_id - SQL Server 上没加
SCHEMABINDING，后续改users表结构导致视图失效；PostgreSQL 没用MATERIALIZED VIEW（9.4+）缓存结果，每次查都重算
真正卡住性能的，从来不是“能不能嵌套”，而是嵌套之后，你是否还能控制执行路径、字段来源和权限边界。一旦失去这些，再多的 WITH 或 /*+ USE_INDEX */ 注释都只是障眼法。
