必须用CROSS JOIN而非JOIN或LEFT JOIN时，是当两表无任何可关联业务字段且明确需全量组合；其语义清晰、意图明确，而隐式JOIN不加ON条件属非标行为，易误读且性能风险高。
什么时候必须用 CROSS JOIN 而不是 JOIN 或 LEFT JOIN
当你需要把表 A 的每一行和表 B 的每一行配对组合，且两表**完全没有可关联的业务字段**（比如没有 user_id、category_id 等），又明确要生成全量组合时，CROSS JOIN 是唯一语义清晰、意图明确的选择。用 JOIN 不加 ON 条件在部分数据库（如 MySQL）中虽能“碰巧”实现笛卡尔积，但属于隐式行为，SQL 标准不保证，且容易被误读为漏写条件。
CROSS JOIN 的写法和常见错误
标准写法就是显式写出 CROSS JOIN 关键字，不带 ON 子句。最容易踩的坑是：在已有 WHERE 条件的情况下，误以为 CROSS JOIN 会自动过滤——它不会，WHERE 是后续筛选，笛卡尔积仍会先完整生成再过滤，可能引发性能爆炸。
- ✅ 正确：
SELECT * FROM products CROSS JOIN regions; - ❌ 危险：
SELECT * FROM products CROSS JOIN regions WHERE regions.country = 'CN';—— 若regions有 100 行、products有 10 万行，先算 1000 万行再过滤，内存和时间都吃紧 - ⚠️ 注意：PostgreSQL 和 SQL Server 强制要求显式写
CROSS JOIN；MySQL 允许FROM a, b写法，但语义模糊，不推荐
替代方案：什么情况下不该用 CROSS JOIN
如果两表其实存在逻辑关系，只是暂时没建外键或字段名不一致，优先修复关联逻辑，而不是硬上笛卡尔积。例如：orders 表有 customer_code，customers 表有 cust_id，这时应写 ON orders.customer_code = customers.cust_id，而非 CROSS JOIN 后用 WHERE 模糊匹配。
- 笛卡尔积结果行数 = 表 A 行数 × 表 B 行数，哪怕各只有 1000 行，也会生成 100 万行，查询可能超时或 OOM
- 如果只是为了补全缺失组合（如“每个用户都要有每种状态的默认记录”），更稳妥的做法是先用
CROSS JOIN生成骨架，再LEFT JOIN原数据做标记，避免重复插入 - 某些 OLAP 场景下，用物化视图预计算 + 缓存比每次跑
CROSS JOIN更实际
用 CROSS JOIN 配合 VALUES 构造测试数据
这是 CROSS JOIN 最安全、最常用的场景：不依赖真实表结构，快速生成组合样本。比如模拟“不同地区 × 不同产品类型 × 不同季度”的汇总维度。
SELECT region, product_type, quarter
FROM (VALUES ('North'), ('South'), ('East'), ('West')) AS t(region)
CROSS JOIN (VALUES ('Electronics'), ('Clothing'), ('Books')) AS u(product_type)
CROSS JOIN (VALUES ('Q1'), ('Q2'), ('Q3'), ('Q4')) AS v(quarter);
这种写法轻量、可控、无副作用，且所有主流数据库（PostgreSQL、SQL Server、Trino、DuckDB）都支持。注意 VALUES 必须用别名（如 t(region)），否则会报错 column "region" does not exist。
实际用的时候，笛卡尔积的规模很容易被低估，尤其是当其中一个表是动态增长的（比如每日新增的用户表）。宁可先 SELECT COUNT(*) 算出乘积结果量，再决定是否执行。
