嵌套视图导致优化器基数估计失准、谓词无法下推、索引失效及强制物化，根源在于统计信息传递中断和多层逻辑遮蔽；三层以上嵌套尤其易触发Materialize/Table Spool/Using temporary等低效执行节点。
嵌套视图让优化器“看不清”数据量
数据库优化器依赖准确的基数估计（即每一步大概返回多少行）来选连接顺序、算法和内存分配。嵌套视图（比如 v3 依赖 v2，v2 又依赖 v1）会切断统计信息的传递链——优化器无法穿透多层定义反推底层表的真实行数分布，只能靠硬编码默认值（如 SQL Server 对远程视图直接估 10000 行）或粗略采样，结果就是：选错哈希连接而非嵌套循环、给排序分配太少内存、甚至误判索引扫描比全表扫描还贵。
WHERE 条件卡在中间层下不去
视图内联（view inlining）本该把外层 WHERE 推到基表扫描前执行，但嵌套超过两层后，多数数据库（尤其是 MySQL 和旧版 SQL Server）会主动放弃下推。典型表现是执行计划里出现 Materialize（PostgreSQL）、Table Spool（SQL Server）或 Using temporary（MySQL）节点——这意味着先算出整个 v2 结果集再过滤，而不是把 WHERE user_id = 123 直接送进 users 表的索引查找里。
- 三层嵌套常见触发点：
v_order_summary→v_order_items→v_product_catalog - 一旦某层含
GROUP BY或DISTINCT，下推基本失效 - 用
pg_get_viewdef('v3')或sp_helptext 'v3'手动展开，再跑EXPLAIN，对比差异最直观
函数/表达式字段让索引彻底失效
如果嵌套视图某一层用了 UPPER(name)、YEAR(create_time) 或 COALESCE(status, 'unknown')，不仅外层条件下推失败，基表上原本可用的索引也完全无法命中。优化器看到的是一个“黑盒计算列”，只能走全表扫描+CPU 计算。
- MySQL 8.0+ 支持函数索引，但必须和视图中写法**字面完全一致**才能用，例如视图里写
YEAR(create_time)，索引就得建在(YEAR(create_time))上 - PostgreSQL 的表达式索引同理，
CREATE INDEX ON orders ((lower(email)))只能加速WHERE lower(email) = 'a@b.com'，对WHERE email = 'A@B.COM'无效 - SQL Server 的计算列索引需要
PERSISTED属性，且视图定义里得直接引用该列名，不能重算
ALGORITHM = TEMPTABLE 是隐形性能杀手
MySQL 默认对含 UNION、GROUP BY 或子查询的视图设 ALGORITHM = TEMPTABLE，这等于强制物化——不管外层有没有 WHERE，都先把整个视图结果写进临时表，再查。用 SHOW CREATE VIEW v_name 一眼就能确认，一旦看到这行，就别指望索引了。
- 替代方案：改用
ALGORITHM = MERGE（需满足合并条件），或干脆不用视图，改写为带WITH的 CTE - SQL Server 没这个参数，但嵌套视图 + 窗口函数同样触发物化，等效于 TEMPTABLE
- 真正高频读场景，不如用物化视图（PostgreSQL 的
CREATE MATERIALIZED VIEW或 SQL Server 的索引视图）预计算
嵌套视图最难调试的点在于：单看某一层定义都合理，但组合起来就崩——问题不出在语法，而出在优化器对多层逻辑的“理解力”边界。越早用 EXPLAIN (ANALYZE, BUFFERS) 或实际执行计划验证，越不容易被表面简洁性误导。
