exists嵌套越深越慢，是因为每层都触发重复执行：外层扫一行，中间层重跑一次，中间层再扫一行，内层又重跑一次，实际复杂度达o(n×m×k)；若任一层缺失索引（type=all）或含函数导致索引失效，性能断崖下跌。
EXISTS嵌套为什么越深越慢？
不是语法写得复杂才慢，而是每层 EXISTS 都会触发一次子查询执行——外层表扫一行，中间层就重跑一遍，中间层再扫一行，最内层又重跑一遍。实际扫描行数可能是 O(n × m × k)，而不是“逻辑上三层”。尤其当某层子查询没走索引（type 显示 ALL 或 index），性能会断崖式下跌。
常见错误现象：EXPLAIN FORMAT=TREE 显示多层 Nested loop，且内层 rows 列数值随外层放大；执行时间随主表数据量非线性增长；CPU 使用率持续 90%+。
- 检查所有关联字段是否都有索引：比如
t2.a = t1.a AND t2.b = t1.b，优先建联合索引INDEX(a, b)，而非两个单列索引 - 避免在子查询
WHERE中对索引字段用函数，如WHERE DATE(create_time) = '2026-06-01'会让索引失效 -
SELECT *在子查询里没意义，统一写成SELECT 1，部分旧版 MySQL 解析更轻量
用 LEFT JOIN + IS NULL 替代 NOT EXISTS
很多人直接把 NOT EXISTS 当作 LEFT JOIN ... IS NULL 的等价写法，但数据库优化器并不总能自动转换，尤其在视图嵌套或三层以上时。显式写出反连接（Anti-Join）才能真正触发高效执行计划。
使用场景：视图中存在类似 WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid') 的逻辑。
-
ON子句必须包含全部过滤条件，例如LEFT JOIN orders o ON o.user_id = u.id AND o.status = 'paid'；若把o.status = 'paid'放到WHERE，就变成先笛卡尔积再过滤，失去反连接语义 - 右表可能返回多行匹配（如一个用户有多笔已支付订单），需加
DISTINCT或按左表主键GROUP BY去重，否则结果行数会膨胀 - 如果右表本身是视图或含函数，先确认该视图是否支持下推过滤——否则
ON条件可能无法生效
把深层 EXISTS 拆出来物化成临时表或 CTE
当嵌套达到三层及以上（比如 A → EXISTS(B → EXISTS(C))），硬改 JOIN 容易逻辑出错，且优化器难生成合理计划。更稳妥的做法是分步剥离：先把最内层子查询结果提前算好，再参与外层关联。
参数差异：WITH CTE 在 MySQL 8.0+ 和 PostgreSQL 中默认不物化（即每次引用都重执行），而 CREATE TEMPORARY TABLE 是真实物化，可控性强；SQL Server 的 WITH 可加 OPTION (RECOMPILE) 强制重估。
- 优先用
CREATE TEMPORARY TABLE tmp_c AS SELECT DISTINCT order_id FROM refunds WHERE status = 'approved'，再在主查询中JOIN tmp_c - CTE 仅用于可读性提升，除非明确加上物化提示（如 PostgreSQL 的
MATERIALIZED关键字） - 物化后记得在临时表上建索引，特别是关联字段，否则只是把扫描压力从子查询转移到了临时表
视图里嵌套 EXISTS 的特殊坑
视图本身不存储数据，每次调用都重解析、重优化。如果视图定义里含多层 EXISTS，且该视图又被其他视图引用，优化器可能放弃半连接优化，退化为嵌套循环，甚至无法复用已有索引统计信息。
容易被忽略的地方：视图字段是否允许 NULL？比如 NOT EXISTS 依赖右表关联字段非空，但若该字段本身可为 NULL，会导致意外漏数据；另外，MySQL 对视图中子查询的索引选择有时不如普通查询激进。
- 在视图定义中显式加
WHERE right_table.id IS NOT NULL，堵住NULL传导路径 - 避免在视图里写
SELECT *，只暴露必要字段，减少后续查询投影开销 - 定期运行
ANALYZE TABLE更新统计信息，尤其在底层表数据分布变化大之后
