90%笛卡尔积问题源于on子句缺失、字段错误或大小写不匹配；mysql无on时退化为cross join，旧版本静默执行致性能灾难，新版本直接报错。
必须检查 ON 子句是否存在、字段是否写对、大小写是否匹配——这是 90% 笛卡尔积问题的根源。
为什么没写 ON 就会出笛卡尔积
MySQL 在执行 JOIN 时，如果缺少 ON 或 USING 条件，会默认退化为 CROSS JOIN。哪怕你写了 LEFT JOIN，只要没跟 ON，就等价于 FROM a, b。结果是：表 A 有 1000 行，表 B 有 500 行，结果集就是 50 万行——全是无效组合。
MySQL 8.0+ 会直接报错 ERROR 1064，但旧版本（如 5.7）可能静默执行，查不出错，只查得慢、占内存、返回垃圾数据。
- 显式写
ON是强制约束，不是可选项 -
USING (col)要求两表该列名完全一致且类型兼容，否则也等同于无条件 - 用
WHERE替代ON在LEFT JOIN中会导致逻辑错误（见下一条）
LEFT JOIN 后误用 WHERE 过滤右表字段
这是最容易被忽略的“伪正确”写法。例如：
SELECT o.order_id, c.name FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active';
表面看是想查“活跃客户的订单”，但实际效果是：所有 c.status != 'active' 或 c.id IS NULL 的订单全被过滤掉，LEFT JOIN 变成 INNER JOIN。更糟的是，如果 c.status 允许 NULL，这部分记录也会消失。
- 业务上要保留左表全部记录？过滤条件必须写进
ON：ON o.customer_id = c.id AND c.status = 'active' - 若需区分“有客户且活跃”和“无客户”，
WHERE只能用于左表字段或c.id IS NULL这类空值判断 - 用
EXPLAIN看type列：如果是ALL或index且rows异常高，大概率条件没生效
字段名拼写、大小写、NULL 值引发的隐性失效
ON o.cid = c.id 看似合理，但如果 orders 表实际字段叫 customer_id，这个条件永远为 false，MySQL 仍会做全量组合——等效于没写 ON。
- 大小写敏感取决于系统变量
lower_case_table_names和列定义，但字段名在 SQL 中默认不区分大小写；不过别依赖它，统一小写最稳 -
NULL = NULL返回UNKNOWN，不是TRUE，所以ON a.id = b.parent_id时，若b.parent_id有 NULL，这些行不会被关联上 - 检查是否有重复值导致意外放大：比如
customers表里id = 123出现 5 次，和orders中 1 条记录关联后就变成 5 行 - 用
SELECT COUNT(*) FROM orders o JOIN customers c ON o.customer_id = c.id;快速验证关联基数是否合理
索引缺失让 ON 条件形同虚设
即使 ON 写对了，没有索引照样慢如笛卡尔积。MySQL 无法快速定位匹配行，只能走嵌套循环（Nested Loop），逐行比对。
-
ON中用到的字段必须建索引，尤其是右表的关联字段（如customers.id） - 复合索引要注意顺序：
ON a.x = b.x AND b.y = 'val'，则b(x,y)比单列b.x更高效 - 用
EXPLAIN看key列是否非NULL，Extra是否出现Using join buffer（说明没走索引） - 注意：主键和唯一索引自动有效；普通字段必须手动
CREATE INDEX idx_customer_id ON customers(id);
真正卡住人的从来不是语法，而是那些“看起来没问题”的 ON 条件——少一个字母、多一个空格、漏一个括号、索引建错表，都会让查询在后台默默爆炸。上线前务必用小数据集 EXPLAIN + COUNT(*) 验证关联结果规模。
