视图中嵌套子查询易触发笛卡尔积，因其被当作静态表与外层表连接时若缺少真实ON关联条件，将导致全量交叉匹配；须确保每层子查询与上层有可驱动索引的ON字段，过滤条件必须写入ON而非WHERE，并仅选取必要字段。
视图里嵌套子查询为什么容易触发笛卡尔积
不是子查询本身危险，而是它被当作“静态表”塞进视图后，和外层表之间若缺少真实关联条件，数据库就只能做全量交叉匹配。比如视图定义里写 LEFT JOIN (SELECT * FROM logs) l ON 1=1，哪怕 logs 只有 1 万行，只要主表是 5 万行，中间结果就是 5 亿行——这在视图被调用时才暴露，但执行计划早已失控。
子查询必须带明确的 ON 关联字段，不能只靠 WHERE 过滤
常见错误是把子查询当“预过滤表”，却忘了它和主表之间仍需业务级连接逻辑。尤其当子查询含 GROUP BY 或去重后，输出结构已变，不能再假设用 id 直接对齐。
- ❌ 危险写法：
LEFT JOIN (SELECT order_id, SUM(amount) FROM payments GROUP BY order_id) p ON 1=1→ 等效于没约束 - ✅ 正确写法：
LEFT JOIN (SELECT order_id, SUM(amount) AS total FROM payments GROUP BY order_id) p ON o.id = p.order_id - 如果子查询不含
order_id（比如只查了customer_id和统计值），那就不能直接JOIN，得改用EXISTS或标量子查询
视图中多层子查询要逐层检查关联粒度
每加一层子查询，都相当于引入一张新临时表；每张临时表和它的上层之间，都必须有可驱动索引的 ON 字段。否则膨胀会指数级放大。
- 检查
EXPLAIN输出中每个子查询节点的rows或actual rows：若远超该子查询实际输出行数，说明关联失效 - 避免在子查询里写
SELECT *，只取后续ON或WHERE中真正用到的字段 - 子查询若含
ORDER BY或LIMIT，优化器可能无法下推，导致全量物化后再裁剪——等于白算
LEFT JOIN 套子查询时，右表过滤条件必须写进 ON
这是最容易被忽略的执行顺序陷阱。放在 WHERE 里，等于先让子查询结果和主表完成全量匹配，再砍掉不满足条件的行；而 ON 才能从源头控制右表参与连接的基数。
- ❌ 错误：
LEFT JOIN (SELECT * FROM customers WHERE deleted = 0) c ON o.customer_id = c.id WHERE c.status = 'active'→ 先拉全部未删除客户，再筛活跃用户，中间已膨胀 - ✅ 正确：
LEFT JOIN (SELECT id, name, status FROM customers WHERE deleted = 0) c ON o.customer_id = c.id AND c.status = 'active' - 如果子查询本身已按
customer_id去重或聚合，AND c.status = 'active'就必须在子查询内部完成，否则ON无法生效
复杂点在于：子查询是否该聚合、按什么字段聚合、要不要提前过滤，这些都不是语法问题，而是得贴着业务规则一条条抠——比如“客户状态为 active”是业务硬约束，漏掉 AND deleted = 0 或 AND is_verified = 1，结果照样错。
