MySQL中漏写ON或USING会导致笛卡尔积，即左表每行与右表每行配对，行数为两表行数乘积；ON条件恒真（如1=1）或无索引列也会引发同样问题，需通过EXPLAIN检查并确保连接字段有索引。
没写 ON 或 USING 就直接 JOIN，笛卡尔积立刻出现
MySQL 在执行 JOIN 时，如果语法里漏掉连接条件（即没有 ON 子句，也没有 USING），优化器不会报错，而是默认走笛卡尔积逻辑。它会把左表每一行和右表每一行暴力配对，结果行数 = 左表行数 × 右表行数。
常见错误场景包括：
- 手误删了
ON后面的条件，只留了SELECT * FROM a JOIN b - 用旧式逗号语法写多表查询，比如
SELECT * FROM a, b WHERE a.id = b.a_id，但不小心把WHERE条件注释或删掉了 - 动态拼 SQL 时，连接条件变量为空，导致最终语句缺失
ON
此时执行计划中 type 字段常为 ALL（全表扫描），rows 值会异常巨大，Extra 里看不到 Using join buffer 或 Using where 等有效过滤提示。
ON 条件写成恒真表达式也会触发笛卡尔积
比漏写更隐蔽的是写了无效的 ON 条件，比如 ON 1=1、ON TRUE、ON a.id > 0（而 a.id 是主键且全为正数）。这些在语法上合法，但语义上等价于无约束，优化器照样生成笛卡尔积。
这类问题多见于：
- 模板化 SQL 中条件未正确替换，占位符残留
- ORM 框架自动生成的关联逻辑被强行绕过（如 Hibernate 的
@JoinColumn配置错误） - 测试环境用
ON 1=1临时“跳过”关联逻辑，上线后忘记改回
可通过 EXPLAIN FORMAT=TREE 观察是否出现 "nested_loop": [ ... ] 且内层无 filter 字段来辅助判断。
优化器不校验 ON 字段是否存在索引，但没索引会让笛卡尔积更难察觉
MySQL 优化器在解析阶段只检查语法合法性，不验证 ON 中的列是否有索引。也就是说，即使你写了 ON a.x = b.y，只要 a.x 和 b.y 都存在，语句就能通过解析——哪怕它们全是 TEXT 类型且没建索引。
后果是：物理执行时只能走嵌套循环（Nested Loop Join），每扫一次左表行，就要全表扫描右表匹配，性能断崖式下跌。而用户往往只看到“慢”，却误以为是数据量大，没意识到本质仍是笛卡尔积规模的遍历。
建议操作：
- 对所有
JOIN的ON列，手动确认是否已有合适索引（注意联合索引顺序） - 在开发/测试环境开启
log_queries_not_using_indexes = ON，捕获这类隐患 - 用
SHOW INDEX FROM table_name快速核对关键字段的索引状态
多表 JOIN 时连接顺序影响笛卡尔积的实际代价
MySQL 8.0+ 的优化器会基于统计信息重排 JOIN 顺序，但前提是每个 ON 条件都有效。一旦某一对表之间缺失或弱化连接条件，优化器可能把小表放在内层、大表放外层，导致实际扫描行数远超理论乘积。
例如：SELECT * FROM orders o JOIN users u ON o.uid = u.id JOIN products p ON 1=1，即使 orders 和 users 关联良好，products 因 ON 1=1 被当作笛卡尔积引入，最终扫描量 ≈ COUNT(orders JOIN users) × COUNT(products)。
这种叠加效应容易被忽略，尤其在三张及以上表连接时。排查时应逐对检查 EXPLAIN 输出中的 table 和 rows，重点看哪一对的 rows 异常放大。
真正危险的不是笛卡尔积本身，而是它藏在看似正常的 JOIN 语法里，靠肉眼很难识别。最稳妥的做法，是在每次新增多表查询后，强制跑一遍 EXPLAIN 并核对每对表的 rows 是否落在合理区间——而不是等线上 OOM 或超时告警才反应过来。
