如何修复MySQL处理多重嵌套视图时出现的查询计划退化？

MySQL嵌套超3层视图会导致优化器放弃代价估算和条件下推，属结构性失效，必须拆解；EXPLAIN中Seq Scan仅显示最外层，实际可能展开多层且WHERE未下推；rows预估与实际偏差超3个数量级即为下推失败铁证。

嵌套超过3层的MySQL视图，优化器会主动放弃代价估算和条件下推——这不是配置能调的，是结构性失效，必须拆解，不能硬扛。

为什么EXPLAIN看起来正常但查询极慢

你看到EXPLAIN里只有Seq Scan on v_orders_summary，不代表它只扫一张表。背后可能是v_customers_active → v_region_map → customers三层展开，而外层WHERE country = 'CN'根本没下推到regions表节点。

• 盯rows列：EstimatedRows和ActualRows差3个数量级以上（比如预估120行，实际扫了150万行），就是条件下推失败的铁证
• 注意select_type：出现DEPENDENT SUBQUERY且rows值远高于基表统计行数，说明子查询被反复执行
• Extra列含Using temporary; Using filesort或Using join buffer (Block Nested Loop)，基本可锁定优化器已降级

用CTE替代嵌套视图时最容易踩的三个坑

CTE不是语法糖，它改写优化器决策路径。错误写法会强制物化、阻断下推，比原视图还慢。

• 在CTE里写SELECT *：多余列阻止外层WHERE下推到底层基表，拖慢I/O和page fault
• 多个CTE交叉引用（如a AS (SELECT * FROM b)，b AS (SELECT * FROM a)）：优化器退化为全物化，失去线性执行优势
• 中间CTE加ORDER BY或LIMIT：触发无谓排序或截断，后续无法复用结果集；MySQL 8.0.23前默认不物化，可能重复执行两次

什么时候该建临时表而不是继续扁平化

当CTE表现不稳定、中间结果超1万行、或需多次JOIN/聚合时，临时表更可控——它让优化器获得准确行数统计，且索引可显式管理。

• 先用CREATE TEMPORARY TABLE tmp_orders AS SELECT ...固化结果
• 立刻执行ALTER TABLE tmp_orders ADD INDEX idx_user_id (user_id)——没索引的临时表JOIN就是全表扫描
• 别用tmp_*这类泛化前缀，ORM可能生成同名表导致冲突
• 若子查询本身含窗口函数或GROUP BY，临时表比CTE更容易让优化器识别真实基数

JOIN能替代的嵌套，优先重写而非拆分

很多所谓“嵌套”，本质是半连接或存在性判断，硬写成子查询反而触发DEPENDENT SUBQUERY。

• 把WHERE id IN (SELECT user_id FROM logs WHERE status = 'success')改成INNER JOIN logs ON t.id = logs.user_id AND logs.status = 'success'
• 必须给logs(status, user_id)建复合索引（等值条件在前）
• 避免JOIN (SELECT ...) AS t这种派生表写法——它仍是黑盒，未必比原写法好
• 若原逻辑是NOT IN，注意NULL值会导致整行丢弃，且无法走哈希连接；优先改用NOT EXISTS并确保logins(user_id, login_time)有复合索引

真正卡点不在语法怎么写，而在人工验证每层的行数分布与索引命中情况——预估和实际偏差一旦超3个数量级，所有优化都只是在补漏，不是治病。