CROSS JOIN必然导致笛卡尔积爆炸，必须前置过滤而非依赖WHERE或LIMIT：先用CTE或子查询筛小表（如orders按日期、product_catalog按热度），再连接；仅允许极小维度表（如12月×34地区）直接交叉连接。
因为不带条件的 CROSS JOIN 会强制生成笛卡尔积，而生产环境的数据量会让这个乘积瞬间超出内存、磁盘和连接池承载能力——不是“可能慢”，而是“必然崩”。
执行计划里 rows 预估超 10 万就该警觉
别靠经验猜，直接看 EXPLAIN 输出：
- 如果 type 是 ALL 或 index，且 rows 显示值远大于任一表的实际行数（比如左表 5 万行、右表 8 万行，rows 却标 4e9），那就是笛卡尔积已坐实
- 出现 Using join buffer 或 Using temporary，说明内存不够，开始落盘排序，性能断崖下跌
- Extra 里有 Using where; Using filesort，但 WHERE 条件是 1=1 或为空，等于优化器已放弃索引选择
加 LIMIT 并不能真正止血
LIMIT 在 CROSS JOIN 后面加，只是最后截断，不是提前剪枝：
- 错误写法：SELECT * FROM a CROSS JOIN b LIMIT 100 → 先算完全部组合（比如 10 亿行），再取前 100 行，照样 OOM
- 正确做法：必须配合 ORDER BY 字段有索引，且把排序+截断逻辑前置，例如：SELECT * FROM (SELECT * FROM a ORDER BY id LIMIT 100) a_sub CROSS JOIN b
- 注意：max_execution_time 在 MySQL 中对 CROSS JOIN 不一定生效，尤其在子查询或 MyISAM 表里完全无效
过滤条件必须写在 JOIN 前，而不是 WHERE 后
多数引擎（包括 Hive、PostgreSQL、SQL Server）不会把 WHERE 条件下推到 CROSS JOIN 的任一侧：
- 危险写法：SELECT * FROM orders CROSS JOIN product_catalog WHERE orders.order_date = '2024-01-01' → 先爆 1000 万 × 5000 行中间结果，再过滤
- 安全写法：用 CTE 或子查询先筛好左表：WITH filtered_orders AS (SELECT * FROM orders WHERE order_date = '2024-01-01') SELECT * FROM filtered_orders CROSS JOIN product_catalog
- 同样适用于右表：如果 product_catalog 实际只需用其中 100 款热门商品，就得先 SELECT * FROM product_catalog WHERE is_hot = 1 再 JOIN
小维度表才配用 CROSS JOIN，业务大表一律禁止
真正合法的 CROSS JOIN 场景极少，只限于可控的小结果集：
- ✅ 可接受：dim_month（12 行） × dim_region（34 行） → 最多 408 行
- ✅ 可接受：用 UNION ALL 构造的枚举表，如血型（4 行）、状态（3 行）→ 组合最多 12 行
- ❌ 禁止：user_logs（日增百万）、events（滚动千亿）、orders（千万级）参与任何 CROSS JOIN
- ⚠️ 特别容易被忽略：开发环境数据量小，EXPLAIN 显示 rows=2000，上线后数据翻十倍，rows 变成 2000 万，优化器依然安静地执行，直到服务器拒绝新连接
