笛卡尔积问题源于join缺失或失效的on条件，导致数据库退化为全表交叉；需通过explain检查type=all、rows异常高、extra含using join buffer等信号快速识别。
因为遗漏 JOIN 条件会让数据库退化为笛卡尔积计算，两表各 10 万行就能生成 100 亿行中间结果——内存瞬间打满、磁盘排序溢出、连接堆积，MySQL 拒绝新连接，PostgreSQL I/O 卡死，不是慢，是直接失联。
ON 子句为空或恒真（如 ON 1=1）时，执行计划怎么识别
别靠猜，直接看 EXPLAIN 输出里的关键信号：
-
type是ALL或index，且rows预估值远超单表实际行数（比如左表 5 万行，rows显示 2000 万）→ 已触发嵌套循环全组合 -
Extra出现Using join buffer或Using temporary→ 内存不够，开始落盘，性能断崖式下跌 -
Extra有Using where; Using filesort，但WHERE实际是空或仅含1=1→ 优化器已放弃索引选择，暴力扫描
PostgreSQL 还可加 EXPLAIN (ANALYZE, BUFFERS) 看真实 I/O 和内存占用；MySQL 5.7+ 推荐用 EXPLAIN FORMAT=JSON 查 rows_estimation 和 join_buffer_size 使用量。
动态拼接 SQL 时 ON 条件丢失的典型表现
这类问题最隐蔽：语法合法、本地跑得通、上线就崩。常见场景包括：
- 变量为空导致
ON ${joinCond}展开成ON（空字符串），MySQL 静默接受，等效于CROSS JOIN - 复制粘贴时漏掉整行
ON，只留了FROM t1 JOIN t2，尤其在多层 CTE 或视图封装后更难察觉 - ORM 框架（如 MyBatis 的
<foreach></foreach>、GORM 的Preload）自动生成 JOIN，但关联字段未加索引 + 动态条件未兜底，ON逻辑被绕过
验证方法很简单：临时把 SELECT * 改成 SELECT COUNT(*)，再对比 COUNT(*) FROM t1 × COUNT(*) FROM t2 —— 若接近，就是笛卡尔积。
LIMIT 能不能救急？为什么经常失效
LIMIT 是线上卡死时最快止血手段，但必须满足前提，否则毫无作用：
- 错误写法：
SELECT * FROM a CROSS JOIN b LIMIT 100→ 数据库仍会先生成全部 10 亿行，再截取前 100，照样崩 - 正确前提：必须配合有索引的
ORDER BY字段，如ORDER BY a.id, b.id LIMIT 100，且a.id和b.id均有索引 → 优化器才可能用索引驱动，提前终止嵌套循环 - MySQL 的
max_execution_time对这种场景大概率不生效：它只在 InnoDB 的顶层SELECT生效，MyISAM、子查询、UNION 或存储过程内均无效
真正可靠的防御不是靠 LIMIT 或超时，而是上线前强制校验：所有用户可触发的 JOIN 查询，必须至少有一个高选择性字段（如 user_id、order_no）非空，且 EXPLAIN 预估行数不超过 50 万。
最容易被忽略的一点：开发环境数据量小，EXPLAIN 的 rows 预估可能是 2 万；生产环境数据翻十倍后，它可能跳到 2000 万——而优化器不会报错，也不会警告，只会安静地把服务器拖垮。
