mysql视图中left join易导致执行计划劣化：驱动表错乱、where无法下推、嵌套使lateral失效、索引不生效，应优先用cte或临时表显式控制执行路径。

视图里LEFT JOIN的执行计划被重写

MySQL（尤其是8.0之前）在把含 LEFT JOIN 的查询封装成视图后，优化器常会“忘记”原查询中已有的驱动表逻辑，强行将右表当作驱动表，或放弃使用索引。比如你写 SELECT * FROM v_orders_with_customer，视图定义里是 orders LEFT JOIN customers ON orders.customer_id = customers.id，但实际执行时可能对 customers 全表扫描再反向匹配——尤其当 customers.id 有索引而 orders.customer_id 没索引时，这种倒置最致命。

视图无法下推WHERE条件到JOIN子句

你在查询视图时加的 WHERE 条件，比如 WHERE o.status = 'paid'，很可能不会被下推到视图定义内部的 ON 或子查询中。结果就是：视图先完成全部 LEFT JOIN 计算（含大量 NULL 行），再过滤，中间结果集爆炸。而直接写 SQL 时，优化器更可能提前用 WHERE 收窄左表，再 JOIN。

• 错误写法：SELECT * FROM v_order_summary WHERE status = 'paid'
• 等效但高效写法：SELECT * FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE o.status = 'paid'

视图嵌套导致LATERAL失效或物化

如果视图本身又引用了其他视图，且其中包含依赖左表字段的子查询（比如查每个订单最新物流），MySQL 很可能把子查询物化为无索引临时表，而不是走 LATERAL 按需执行。视图层级越深，这种退化越明显——哪怕你用了 LATERAL，外层视图包装后也可能被“扁平化失败”，最终变成全量扫描右表再 GROUP BY 或 ORDER BY ... LIMIT 1，性能断崖式下跌。

索引在视图中不自动生效

视图不存储元数据，也不继承索引语义。即使你在基表上建了 (customer_id, status) 联合索引，视图查询仍可能因统计信息不准、别名混淆或表达式包裹（如 COALESCE(c.name, 'N/A')）导致索引失效。更隐蔽的是：视图字段若做了计算或类型转换（比如 DATE(created_at)），对应基表上的索引就完全用不上。

真正关键的不是“能不能用视图”，而是“有没有让优化器看清你的意图”。复杂 LEFT JOIN 场景下，视图容易掩盖执行路径，不如把核心逻辑拆成带明确提示的临时表或 CTE，至少能控制中间结果规模。