CROSS JOIN 必然导致 CPU 满载，因其强制生成笛卡尔积，引发 O(M×N) 逻辑读、内存/磁盘排序及嵌套循环满载运算；仅当两表均为小维度表（如月维×区域维，结果<千行）时才安全。
因为 CROSS JOIN 不做任何行级过滤，数据库必须为左表每一行匹配右表全部行，生成完整笛卡尔积——这直接触发高逻辑读、大量内存/临时磁盘排序，CPU 在嵌套循环中持续满载运算，不是“可能高”，而是“必然打满”。
为什么执行计划里 type=ALL 且 rows 爆炸就等于 CPU 必然飙升
当 EXPLAIN 显示 type 是 ALL 或 index，且 rows 列数值远超任一表实际行数（比如左表 5 万、右表 8 万，rows 却标 4e9），说明优化器已放弃剪枝，进入纯嵌套循环模式：
- 每一轮内层循环都要重新扫描右表全量数据（或索引），逻辑读呈 O(M×N) 增长
- MySQL 的
join buffer装不下时，会 fallback 到磁盘临时表 + filesort，CPU 花在序列化/反序列化和排序上 - SQL Server 中表现为
WRITELOG等待 + 高% User Time，PostgreSQL 则频繁触发temp_file_limit中断
CROSS JOIN + WHERE 条件 ≠ 安全写法
把过滤条件写在 WHERE 子句里（如 SELECT * FROM a CROSS JOIN b WHERE a.id = b.a_id），绝大多数引擎（SQL Server、PostgreSQL、Hive）不会下推该条件到任一侧，仍先算完全部组合再过滤：
- 错误示例：
SELECT * FROM orders CROSS JOIN product_catalog WHERE orders.order_date = '2024-01-01'→ 先生成千万 × 五千行中间结果 - 正确做法：用 CTE 或子查询提前筛出小结果集，例如
WITH filtered_orders AS (SELECT * FROM orders WHERE order_date = '2024-01-01') SELECT * FROM filtered_orders CROSS JOIN product_catalog - 注意：即使加了
ORDER BY id LIMIT 100，若没前置子查询，排序仍发生在十亿行之后，CPU 已经烧完
什么情况下 CROSS JOIN 才不明显拖垮 CPU
仅当两侧都是可控的小维度表，且结果集行数在千级以内时，CPU 开销才可接受：
- ✅ 合法场景：
dim_month（12 行） ×dim_region（34 行）→ 最多 408 行，内存常驻，无落盘 - ✅ 合法场景：用
VALUES构造的枚举驱动表，如(VALUES (1),(2),(3)) AS v(n)×(VALUES ('A'),('B')) AS c(code)→ 6 行 - ❌ 危险场景：哪怕只对
users（10 万行）和events（日增百万）做一次CROSS JOIN，中间结果就是千亿级，CPU 满载后进程常被 OOM killer 终止
真正难防的不是语法本身，而是业务同学看到“交叉”就以为是“关联”，随手把大表扔进 CROSS JOIN——它不像 INNER JOIN 有 ON 提示，也没有语法报错，直到监控告警 CPU 持续 95%+，才去翻执行计划里的 rows 字段。
