直接给出核心结论：当MySQL中的嵌套视图层数超过3层时，优化器会自动放弃代价估算与条件下推机制。这并不是通过调整配置就能解决的，而是属于结构性失效。因此必须从根源上进行拆解，而不能尝试硬扛。

很多开发者遇到这类问题时，习惯性地只关注EXPLAIN的输出。他们看到Seq Scan on v_orders_summary，以为优化器只需要扫描一张表，从而感到放心。但实际上，背后可能隐藏着v_customers_active → v_region_map → customers三层视图的逐层展开，而外层的WHERE country = 'CN'条件根本没有被下推到regions表的节点上。

要从EXPLAIN中定位问题，需要关注以下几个关键的排查信号：

• 观察rows列：如果EstimatedRows与ActualRows之间的差值超过三个数量级（例如预估120行，实际扫描150万行），则这是条件下推失败的有力证据，几乎无需怀疑。
• 查看select_type：若出现DEPENDENT SUBQUERY，且rows值远大于基表的统计行数，则表明子查询被重复执行——这正是不良设计导致的“每次扫描都执行一次”。
• 检查Extra列：一旦出现Using temporary; Using filesort或Using join buffer (Block Nested Loop)，基本可以断定优化器已降级使用低效策略，查询计划明显处于不良状态。

使用CTE替代嵌套视图时最容易陷入的三个误区

许多开发者的第一反应是用CTE替代嵌套视图，这个思路本身正确。然而CTE并不仅仅是语法糖；它会影响优化器的决策路径。如果使用不当，可能会强制物化、阻止条件下推，最终导致性能甚至比原始视图还要差。

• 在CTE中使用SELECT *：这看起来省事，实际上是重大隐患。多余的列会阻止外层WHERE条件向下传递到底层基表，从而增加I/O和页面错误，得不偿失。
• 多个CTE互相引用：例如a AS (SELECT * FROM b)，b AS (SELECT * FROM a)，这种模式会导致优化器退化为完全物化，失去线性执行的优势。实际上把问题从视图嵌套转变为CTE的循环依赖。
• 在中间CTE中添加ORDER BY或LIMIT：这会引发不必要的排序或截断，使后续操作无法重用结果集。并且在MySQL 8.0.23之前，CTE默认不会被物化，可能导致相同逻辑被重复执行两次。

何时应该创建临时表而非持续扁平化

在某些场景下，强行扁平化反而不如直接创建临时表。当CTE的表现不稳定、中间结果集超过一万行、或者需要多次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，导致性能急剧下降。此时应优先尝试使用JOIN进行重写。

• 将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)建有复合索引。

归根结底，真正的瓶颈不在于语法的写法，而在于你是否能人工验证每一层的行数分布与索引命中情况。当预估与实际值偏差超过三个数量级时，所有的优化措施都只是在修补表面，而非解决根本问题。这才是问题的关键所在。