笛卡尔积导致结果集爆炸式增长，索引无法阻止组合逻辑，仅加速单表过滤；EXPLAIN显示用索引但执行卡死，因实际扫描行为是匹配行数的乘积，而非单表行数。
笛卡尔积本身就会导致结果集爆炸式增长，索引对此完全无能为力——它解决的是“如何快速定位数据”，而不是“如何避免生成海量组合”。
为什么EXPLAIN显示用了索引，但执行仍卡死
MySQL 的 EXPLAIN 可能显示某张表走了索引（比如 type=ref 或 range），但这只说明单表扫描路径被优化了；一旦 JOIN 触发笛卡尔积，实际扫描行数 = 表A匹配行数 × 表B匹配行数。哪怕每张表都只扫 1 万行，组合后就是 1 亿行中间结果。
- 索引无法减少 JOIN 的组合逻辑，只能加速单表的条件过滤
-
rows列在EXPLAIN中显示的是预估单表扫描行数，不是最终结果集大小 - 如果没写
ON或WHERE关联条件，EXPLAIN甚至可能显示type=all+rows=N×M，但很多人忽略这一行
哪些写法会悄悄触发笛卡尔积
不是只有显式省略 JOIN ... ON 才会出问题，以下常见场景都会等效于笛卡尔积：
- 多表
FROM t1, t2, t3写法，但WHERE中漏掉任意一对关联条件（如漏了t2.id = t3.parent_id） -
LEFT JOIN后跟了一个没有关联条件的子查询或派生表 - 使用
IN (SELECT ...)且子查询未关联外层表，优化器可能转成物化 + 嵌套循环，效果类似笛卡尔积 - 视图展开后丢失了原始 JOIN 条件（尤其跨多层视图嵌套时）
如何快速识别和终止正在发生的笛卡尔积查询
别等它跑完——这类查询往往在 Sending data 状态卡住数分钟，期间持续消耗 CPU 和内存。
- 用
SHOW PROCESSLIST查看状态，重点关注State列为Sending data且Time持续上涨的连接 - 结合
EXPLAIN FORMAT=TREE（MySQL 8.0+）看是否出现> nested loop join下挂多个未关联的表扫描分支 - 紧急时直接
KILL [id]终止，避免拖垮整个 Buffer Pool - 临时加
LIMIT 100测试逻辑，但注意：LIMIT在笛卡尔积之后才生效，不能降低计算量
真正有效的缓解手段
加索引、调 Buffer Pool、换 SSD 都没用——根源不在 IO 或内存，而在 SQL 逻辑本身。
- 强制补全所有
ON条件，宁可加ON 1=1占位再检查语义，也不要留空 - 把大表 JOIN 拆成两步：先用索引查出主键 ID 列表，再用
WHERE id IN (...)分批拉取详情 - 确认业务是否真的需要笛卡尔积；99% 的情况是误写，而非设计需求
- 在应用层做分页时，避免在笛卡尔积结果上直接
LIMIT offset, size—— offset 越大越慢，因为 MySQL 仍要生成全部中间结果
最危险的不是没索引，而是看着 key 列有值、type 是 ref 就以为万事大吉。笛卡尔积会让所有单表优化失效，而且不报错、不警告，只默默吃光资源。
