最常见笛卡尔积源头是视图中JOIN漏写ON条件，如FROM orders JOIN customers；SQL Server/PostgreSQL直接报错，MySQL老版本可能静默转为CROSS JOIN，导致行数爆炸。
检查视图定义里的JOIN是否漏写ON条件
最常见也最容易被忽略的笛卡尔积源头，就是视图SQL里写了JOIN但根本没写ON。比如FROM orders JOIN customers——这在SQL Server或PostgreSQL中会直接报错，但在MySQL老版本或某些ORM生成语句里可能静默转成CROSS JOIN，结果就是orders行数 × customers行数。
实操建议：
- 用
SELECT OBJECT_DEFINITION(OBJECT_ID('v_sales_summary'))（SQL Server）或pg_get_viewdef('v_sales_summary')（PostgreSQL）把视图定义捞出来，逐行扫JOIN关键字后面有没有紧跟着ON或USING - 特别注意嵌套视图：上层视图
JOIN了下层视图，而下层视图本身已含JOIN，容易误以为“条件已覆盖”，实际可能漏掉某一层的约束 - 如果看到
LEFT JOIN logs l ON 1=1这类写法，基本可以确定是开发临时调试留下的残骸，必须删掉或补全真实关联字段
验证JOIN字段是否存在索引且类型严格匹配
有ON a.id = b.a_id不等于就安全。如果a.id是BIGINT而b.a_id是VARCHAR，或者其中一列加了函数如UPPER(b.name)，索引就失效，优化器被迫走嵌套循环+全表扫描，中间结果集瞬间膨胀。
实操建议：
- 查执行计划时重点看
key列是否为空、type是否为ALL或index（MySQL）、Node Type是否出现Nested Loop且Actual Rows远超左表行数（PostgreSQL） - 用
DESCRIBE table_name或sp_help 'table_name'确认字段类型，避免隐式转换 - 给每个JOIN字段单独建索引，不要依赖复合索引——例如
orders.customer_id和customers.id都得有独立索引，否则连接时仍可能失效
警惕LEFT JOIN右侧表无约束导致的结果放大
LEFT JOIN本身不会产生笛卡尔积，但右边表若未加有效过滤，一行左表记录可能匹配右表多行，尤其当右表是聚合结果或日志类宽表时，放大效应极明显。比如LEFT JOIN order_items oi ON o.id = oi.order_id，若order_items里一个订单有50条明细，那这个订单在视图结果里就会展开成50行。
实操建议：
- 把能缩小右表范围的条件显式挪进
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 - 对右表加
LIMIT 1测试（仅限排查）：如果LEFT JOIN (SELECT * FROM logs LIMIT 1) l ON ...后结果行数正常，说明原右表确实存在多对一膨胀
用EXPLAIN快速定位哪一步JOIN开始膨胀
别等应用报超时才查。在视图查询前加EXPLAIN（MySQL）或EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL），盯住每一步的rows预估值和filtered百分比。
实操建议：
- 如果某步
rows从1万跳到800万，而filtered只有0.5%，说明99.5%的中间行被后续条件干掉了——这部分条件本该提前到ON里 - MySQL中
type: ALL+key: NULL组合，基本锁定该表JOIN时没走索引 - PostgreSQL中留意
Nested Loop节点下Actual Rows是否远大于左表输入行数，这是笛卡尔积最直接的证据
真正难处理的不是语法错误，而是那些“看起来合法”的JOIN：比如ON a.x = b.y OR a.z = b.w、LEFT JOIN (SELECT ...) t ON 1=1、或者跨时区字段用CONVERT_TZ做关联——它们不会报错，但会让优化器彻底放弃索引选择，最终在数据量稍大时无声崩塌。
