执行EXPLAIN发现Materialize节点超60%或反复出现Derived/Subquery Scan，即可断定视图链失控；人工追踪依赖时，MySQL用SHOW CREATE VIEW逐层查、PostgreSQL查pg_depend但需手动补链、SQL Server用sys.dm_exec_describe_first_result_set验列一致性。
怎么一眼看出视图链已经变成意大利面
查 INFORMATION_SCHEMA.VIEWS 或 pg_views（PostgreSQL）、sys.views（SQL Server）本身没用——关键得顺藤摸瓜。真正有效的起点是：执行 SELECT * FROM v_report 时跑 EXPLAIN，如果看到 Materialize 节点占比超 60%，或执行计划里反复出现 Derived / Subquery Scan，基本可以断定视图链已失控。
更直接的判断方式是人工追踪依赖：
- MySQL：用
SHOW CREATE VIEW v_report看定义，再手动搜其中引用的v_summary，再搜v_summary里有没有v_base—— 超过两层就该警觉 - PostgreSQL：查
pg_depend，但注意它只记录直接依赖，v_kpi → v_region → v_base这种链式关系不会自动连起来 - SQL Server：
sp_depends已弃用，改用sys.dm_exec_describe_first_result_set(N'SELECT * FROM v_kpi')，但如果返回列名全为NULL或数量对不上，说明中间某层已被破坏
为什么不能靠“重命名+重建”来修嵌套视图
很多人以为把 v_sales_base 改成 v_sales_core，再 CREATE OR REPLACE VIEW v_sales_region AS ... 就完事了。错。数据库不缓存语义依赖，只做静态列名校验。
以下操作看似合理，实则埋雷：
- 在
v_sales_base里把order_amount改成total_amount，但v_sales_region仍用旧字段名 —— 上层查询报错位置指向v_sales_kpi，而非真实出问题的v_sales_base - 用
CREATE OR REPLACE VIEW更新中间层后，上层视图不会自动刷新元数据，SELECT * FROM v_kpi可能返回字段错位、类型不匹配甚至空结果 - 测试库漏建某一层（如没建
v_sales_region），应用查不到数据但无报错，只返回空集，日志里连 SQL 都没留痕
用 CTE 替代嵌套视图时必须避开的三个硬坑
CTE 不是语法糖，它是让优化器看清数据流的结构化表达。写错比不写还糟。
-
SELECT *必须禁用：中间 CTE 如last_order AS (SELECT * FROM orders)，会导致外层WHERE user_id = 123根本无法下推到orders表扫描节点 - 禁止交叉引用：像
WITH a AS (SELECT * FROM b), b AS (SELECT * FROM a)这种写法，SQL Server 和 PostgreSQL 都会强制全物化，失去条件下推能力 -
ORDER BY和LIMIT慎用：除非真需要排序结果，否则它们会让 CTE 结果不可复用，后续 JOIN 只能重算 —— 特别是在 MySQL 8.0.23 之前，没有MATERIALIZED提示，这种写法等于主动放弃优化
什么时候该停手，直接建临时表
当某段逻辑被多次引用，或本身含窗口函数、大表 JOIN、全表聚合时，CTE 每次都会重算。这不是优化瓶颈，而是设计误判。
典型信号包括：
- 同一段聚合逻辑（如
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id）在多个 CTE 或最终 SELECT 中重复出现 - 中间结果被用于 JOIN + WHERE EXISTS + ORDER BY 三处以上
- 执行计划显示某一步骤
Actual Total Time占比持续高于 40%，且Rows Removed by Filter极低（说明大量无效计算）
这时该用临时表：SELECT user_id, COUNT(*) AS order_cnt INTO #user_stats FROM orders GROUP BY user_id，立刻对 user_id 建索引：CREATE INDEX IX_user_stats_uid ON #user_stats (user_id)。复杂点永远在数据边界上——比如用户没下单导致 #user_stats 为空，LEFT JOIN 后字段全为 NULL，业务代码却没判空。
