视图JOIN过多导致执行计划失效，因优化器将其视为“黑盒”而非展开重优化，造成基数估算失准、驱动表选错、索引失效、谓词无法下推及物化开销剧增。
视图JOIN时执行计划被当成“黑盒”处理
数据库优化器不会把视图展开后再重做连接顺序和驱动表选择，而是把它当作一个整体节点参与外层优化。比如视图定义是 FROM orders JOIN users JOIN order_items，外部再 JOIN v_customer_summary，优化器看到的不是 4 张表，而是两个“盒子”：v_customer_summary 和你写的这个多表视图。它无法准确估算中间结果集大小，EXPLAIN 里 rows 常严重偏低（预估 100 行，实际扫描 80 万），驱动表选错、索引失效就成常态。
谓词下推在嵌套视图中大概率失败
你在外部写 WHERE u.status = 'active'，但视图内部是 LEFT JOIN users u ON o.user_id = u.id，这个条件几乎不可能下推到 users 表扫描层。执行计划里会看到基表扫描节点上 rows = 2000000，最后才靠一个 Filter 节点筛出 12 行——这就是物化全量再过滤的典型信号。更糟的是，如果视图 A 引用了视图 B，B 又含 GROUP BY 或 UNION，下推基本放弃。
- PostgreSQL 中出现
Materialize节点 - SQL Server 中出现
Table Spool+ 后续大 Filter - MySQL 中
type = ALL且Extra含Using temporary
视图定义里埋了破坏下推能力的结构
一旦视图 SQL 包含这些成分，优化器就倾向于走物化路径，而非逻辑展开：
-
SELECT *：拉回所有列，哪怕只用其中 1 个字段，IO 和内存压力翻倍，部分数据库连列裁剪都做不了 -
ORDER BY或LIMIT：干扰条件下推，外部加WHERE也难以下沉 -
UPPER(name)、created_at::DATE等表达式：字段失去原始索引能力，WHERE name = 'abc'无法命中name索引 -
CAST(o.user_id AS VARCHAR)在ON条件中：强制对右表每行做类型转换，索引彻底失效
跨库或远程视图让基数估计完全失准
SQL Server 对远程视图硬编码基数为 10000 行，而对四部分命名的远程基表（如 LS1.DB.Sales.SalesOrderDetail）能通过驱动读取真实统计信息。结果就是：查视图时优化器误选 Nested Loops，反复远程调用；查基表却能生成 Hash Join，且 WHERE 条件可下推。MySQL 和 PostgreSQL 的远程访问也有类似问题，只是表现不同——本质都是统计信息不可得。
真正卡住性能的，从来不是“JOIN 这个动作”，而是视图封装后，你再也看不见、控不住、猜不准底层发生了什么。哪怕索引建得再对，只要视图定义里混进一个 UPPER() 或漏掉一个 AND u.status = 'active' 在 ON 子句里，整个查询就从毫秒掉到秒级。
