视图嵌套子查询本身不慢，慢的是数据库被迫重复执行、无法下推条件或无法合并逻辑；尤其嵌套超三层时，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 */ 注释都只是障眼法。