外连接不会使优化器失效，但会限制其重写空间；若WHERE中含右表字段的非空条件（如c_nationkey IS NOT NULL），则破坏外连接语义，优化器无法安全转为内连接，可能错过更优执行路径。
外连接本身不会让优化器“失效”，但会显著限制优化器的重写空间——尤其是当外连接语义被 WHERE 条件无意中破坏时，优化器可能无法安全地将其转为内连接，从而错过更优执行路径。
WHERE 中的 NULL 拒绝条件是否生效？
这是最关键的判断点。外连接（如 LEFT JOIN）本意是保留左表全部行，右表无匹配则补 NULL。但如果 WHERE 子句里写了右表字段的非空约束（比如 c_nationkey ），那就等价于“右表必须有匹配行”，此时该 <code>LEFT JOIN 在逻辑上已退化为 INNER JOIN。
但优化器能否识别并转化，取决于：
- 该条件是否明确作用于右表字段（不能是表达式或函数包裹，如
COALESCE(c_nationkey, 0) 就不满足） - 该字段是否允许为
NULL（若定义为NOT NULL，WHERE c_nationkey 就不是 NULL 拒绝条件） - MySQL 版本是否支持该类转换（8.0.24+ 更稳定，5.7 可能跳过）
视图定义中嵌套外连接 + GROUP BY / DISTINCT 的副作用
视图一旦包含 GROUP BY、DISTINCT 或聚合函数，MySQL 通常会将整个视图物化为临时表再参与后续连接——这直接绕过了外连接的谓词下推机会。
例如：
CREATE VIEW v_orders_customers AS SELECT o.order_id, c.cust_name, COUNT(*) cnt FROM orders o LEFT JOIN customer c ON o.custkey = c.custkey GROUP BY o.order_id, c.cust_name;即使外部查询加了
WHERE c.cust_name IS NOT NULL，优化器也很难把该条件“下推”进视图内部去触发外→内转换，因为分组已固化了结果结构。
EXPLAIN 中看到 type=ALL 或 extra=Using temporary/Using filesort 就说明问题
如果对视图执行 EXPLAIN，发现：
-
type是ALL（全表扫描）而非ref或eq_ref -
extra出现Using temporary或Using filesort -
key为空，而possible_keys显示本应可用的索引
WHERE 却用了 HAVING），或者是否在外部查询中用到了无法下推的表达式（如 UPPER(c.cust_name)）。
真正难处理的不是外连接本身，而是视图封装后丢失了原始连接语义的上下文——优化器看不到“这个 NULL 是真缺失，还是被 WHERE 过滤掉的”，也就没法做安全转化。
