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个数量级，所有优化都只是在补漏，不是治病。
