笛卡尔积必然发生于缺失有效连接条件时，无论数据量大小；join无on即等价cross join，导致行数爆炸、内存溢出或结果虚胖，且explain可暴露异常扫描行数。
直接结论：笛卡尔积不是“可能出问题”，而是只要缺少有效连接条件，就一定会发生——它不看数据量大小，只看语法是否放行。内存溢出只是结果之一，更常见的是查出几百万行却以为只该有几百行。
JOIN 语句没写 ON 条件，就是默认触发笛卡尔积
这是最直白、最高频的错误。比如 SELECT * FROM users, orders 或 SELECT * FROM users JOIN orders（后面没跟 ON），数据库根本不会报错，而是安静地算完所有组合再返回。
- 哪怕两张表各只有 1000 行，结果就是 100 万行；上万行时，直接触发
ERROR: out of memory或查询超时 -
LEFT JOIN和INNER JOIN都一样危险——没ON就等价于CROSS JOIN - 别信“我只查几个字段所以没事”，字段数不影响行数爆炸，只影响单行内存占用
ON 条件写错字段或类型不匹配，等于没写
写了 ON 不代表安全。如果关联字段逻辑不对，照样产生大量无效匹配。
-
ON users.name = orders.customer_name：名字重复太常见，一个“张三”匹配 20 个订单，就变成 20 倍膨胀 -
ON users.id = orders.user_id但orders.user_id是VARCHAR而users.id是INT：隐式转换可能导致索引失效，优化器退化为全表扫描+嵌套循环，中间结果暴涨 -
ON a.id = b.a_id AND b.status = 'active'放在LEFT JOIN的ON里，会导致左表每行都保留，右表只过滤出 active 行——但若右表无匹配，仍生成 null 行，数量不变；真正想过滤，得挪到WHERE
多表连接时，漏掉任意一对表的 ON 条件
三张表连查：users JOIN orders JOIN products，必须有两组 ON：一组连 users→orders，一组连 orders→products。漏掉任何一个，就会在那一步产生笛卡尔积。
- 例如
users JOIN orders ON users.id = orders.user_id JOIN products（缺ON orders.product_id = products.id）：orders × products先炸开，再和users连——中间结果可能比最终结果大几十倍 - 用
EXPLAIN看执行计划时，注意rows列：如果某张表预估扫描行数远大于其实际行数（比如orders表本身 10 万行，但EXPLAIN显示 join 时要读 500 万行），大概率是关联松动或条件缺失 - 别依赖
DISTINCT补救——它在最后去重，前面该占的内存一点没少，还多一次排序
外键未建、索引缺失，让笛卡尔积更难被发现
即使写了正确的 ON 条件，如果字段没索引或外键约束，数据库可能无法高效定位匹配行，被迫用哈希连接或归并连接，内存占用陡增，且慢查询日志里看不出明显错误。
-
orders.user_id没索引？INNER JOIN时，数据库对每条users行都要扫一遍orders全表——1000 行 × 10 万行 = 10 亿次比较 - 没外键约束，
user_id大量为NULL或指向不存在的users.id，LEFT JOIN后出现大量空匹配，结果集虚胖 - 验证方式：对关键关联字段运行
SHOW INDEX FROM orders WHERE Column_name = 'user_id';，为空就立刻补CREATE INDEX idx_orders_user_id ON orders(user_id);
最容易被忽略的点是：笛卡尔积往往在测试环境不暴露——因为数据量小、字段重复少、索引碰巧存在。一上生产，用户表 50 万行、订单表 200 万行，ON name = name 这种写法瞬间让内存打满。别等报错才查，每次写多表 JOIN 时，强制自己默念一遍：这张表和下一张表，靠哪两个字段一对一/一对多对应？这两个字段有没有索引？
