MySQL老版本视图漏写ON会静默转CROSS JOIN，LEFT JOIN右表无约束或类型不匹配致结果膨胀，应检查JOIN条件、字段类型及索引并优化执行计划。
视图定义里漏写 ON 条件，数据库可能静默转成 CROSS JOIN
MySQL 5.7 或更早版本在视图中写 FROM orders JOIN customers 却没跟 ON 子句时，不会报错，而是自动当作 CROSS JOIN 处理。SQL Server 和 PostgreSQL 则会直接拒绝执行，但很多遗留视图是用 MySQL 老版本建的，上线后一直没暴露——直到某天订单表涨到百万级，v_sales_summary 查询返回上亿行。
实操建议：
- 用
SELECT OBJECT_DEFINITION(OBJECT_ID('v_name'))（SQL Server）或pg_get_viewdef('v_name')（PostgreSQL）把视图 SQL 拿出来，逐行扫每个JOIN后面有没有紧跟着ON或USING - 特别注意嵌套视图：上层视图
JOIN了下层视图，而下层视图本身已含JOIN，容易误以为“条件已覆盖”，实际某一层根本没写ON - 看到
LEFT JOIN logs l ON 1=1这类写法，基本是开发调试留下的残骸，必须删掉或补全真实字段
LEFT JOIN 右侧表未加有效过滤，结果行数被隐式放大
LEFT JOIN 本身不等于笛卡尔积，但右表若无约束，一行左表记录可能匹配右表多行。比如 orders 表 10 万行，order_items 表平均每个订单 20 条明细，结果就是 200 万行——这不算笛卡尔积，但效果类似：查询变慢、内存爆满、下游应用解析失败。
实操建议：
- 把能缩小右表范围的条件显式挪进
ON，而不是放在WHERE：把WHERE oi.status = 'shipped'改成ON o.id = oi.order_id AND oi.status = 'shipped' - 右表先预聚合：用
LEFT JOIN (SELECT order_id, COUNT(*) cnt FROM order_items GROUP BY order_id) oi_agg ON o.id = oi_agg.order_id - 别依赖
DISTINCT补救：它只去重最终结果，中间膨胀仍会发生，IO 和内存开销照旧
视图里字段类型不一致，索引失效导致优化器走嵌套循环
即使写了 ON a.id = b.a_id，如果 a.id 是 BIGINT 而 b.a_id 是 VARCHAR，MySQL 就会对其中一列做隐式转换，索引无法使用。执行计划里 type 显示 ALL，rows 值远超表实际行数，就是典型信号。
实操建议：
- 用
DESCRIBE table_name或sp_help 'table_name'确认字段类型，避免隐式转换 - 给每个
JOIN字段单独建索引，不要依赖复合索引——orders.customer_id和customers.id都得有独立索引 - 在 PostgreSQL 中看执行计划里的
Nested Loop节点下Actual Rows，如果比左表行数高一两个数量级，八成是类型不匹配或没索引
视图嵌套聚合 + 多表 JOIN，中间结果集爆炸不可控
一个带 GROUP BY 的视图再 JOIN 两张大表，优化器可能先算聚合、再连表，也可能先连表、再聚合——顺序不同，中间结果集大小差几个数量级。比如千万级订单表和百万级用户表没加过滤就 JOIN，光中间结果就可能突破百亿行。
实操建议：
- 用
SET STATISTICS XML ON（SQL Server）或EXPLAIN (ANALYZE)（PostgreSQL）看执行计划里有没有Cartesian Product字样，或Estimated Number of Rows异常巨大 - 临时绕过视图，把视图定义里的 SQL 拆出来单独跑，确认是视图本身问题，还是调用上下文（如参数嗅探）引发的偏差
- 避免在视图定义里写
SELECT *；聚合视图尤其要剔除无用的TEXT或XML字段，减少数据搬运量
INT 改成 VARCHAR），却忘了同步更新所有引用它的视图定义——这时 ON 条件还在，索引也还在，但已经完全失效了。 
