加on子句仍出现笛卡尔积，主因是连接条件无约束力：字段重复、含null、类型不匹配或left join后误用where过滤从表字段；需检查拼写、大小写、索引、外键及数据分布。
加了 ON 子句还出笛卡尔积，大概率不是语法写错了，而是连接条件本身没约束力——比如字段值重复、含 NULL、类型不匹配，或者 LEFT JOIN 后误用 WHERE 过滤从表字段。
检查 ON 子句是否存在且字段名拼写正确
MySQL 8.0+ 会直接报 ERROR 1064，但旧版本可能静默退化为 CROSS JOIN。最常见的是字段名写错（如把 order_id 写成 orderid），或大小写敏感导致匹配失败（尤其在 Linux 环境下表名/字段名区分大小写）。
- 执行
EXPLAIN查看type列：若出现ALL或index且rows值极大，说明没走索引，连接条件可能未生效 - 手动验证
ON两侧字段是否真实存在：比如SELECT COUNT(*) FROM orders WHERE customer_id IS NOT NULL和SELECT COUNT(*) FROM customers WHERE id IS NOT NULL - 确认外键关系是否真实成立：不要只看命名习惯，查
INFORMATION_SCHEMA.KEY_COLUMN_USAGE或建表语句里的FOREIGN KEY定义
排查关联字段的重复值与 NULL
一对多关系本身不导致笛卡尔积，但「主表某 ID 出现多次 + 从表同一 ID 也出现多次」就会指数级放大结果行数。例如 orders 表里有 2 条 order_id = 1001，order_items 表里有 5 条 order_id = 1001，JOIN 后就是 10 行——这不是 bug，是数据逻辑冗余。
- 查重复：
SELECT order_id, COUNT(*) FROM orders GROUP BY order_id HAVING COUNT(*) > 1 - 查 NULL：
SELECT COUNT(*) FROM orders WHERE customer_id IS NULL；若用LEFT JOIN，NULL会导致左表该行保留但右表无匹配，看似“没膨胀”，但后续加WHERE过滤右表字段时会意外丢行 - 注意隐式转换：如
orders.customer_id是BIGINT，customers.id是VARCHAR，即使值相同，JOIN 也会全表扫描，优化器可能放弃嵌套循环而选哈希连接，中间结果集暴涨
避免 LEFT JOIN 后用 WHERE 过滤从表字段
LEFT JOIN ... WHERE b.field IS NOT NULL 看似等价于 INNER JOIN，但执行顺序是先完成全量左连接，再过滤。一旦左表或右表数据量大，中间结果集极易爆炸。
- 错误写法：
SELECT o.* FROM orders o LEFT JOIN order_items i ON o.order_id = i.order_id WHERE i.order_id IS NOT NULL - 推荐改用
EXISTS：SELECT o.* FROM orders o WHERE EXISTS (SELECT 1 FROM order_items i WHERE i.order_id = o.order_id)—— 半连接，找到第一个匹配即停，不生成中间行 - 如果必须取从表字段（如商品名、数量），就无法绕开 JOIN，此时务必确保
order_items(order_id)或(order_id, item_id)上有有效索引
用 LIMIT 快速验证膨胀程度
线上不敢跑全量？加 LIMIT 100 是最直接的判断手段。它不解决根本问题，但能快速告诉你：当前 SQL 是否已严重膨胀、膨胀到什么量级。
- 执行
SELECT COUNT(*) FROM (...) t LIMIT 1可绕过全表统计，秒出结果 - 对比
SELECT COUNT(*) FROM orders和SELECT COUNT(*) FROM orders o JOIN order_items i ON o.order_id = i.order_id LIMIT 1000的返回行数，若后者远大于前者，基本坐实笛卡尔积已发生 - 注意：别在生产环境对大表直接跑
SELECT *，哪怕加了LIMIT，也可能因未命中索引而锁表或拖慢其他查询
真正难处理的不是漏写 ON，而是连接条件“看起来对”，但因数据质量、类型隐式转换、索引缺失或 WHERE 位置不当，让优化器无法剪枝——这些细节在线上压测阶段最容易被忽略。
