CROSS JOIN是SQL中明确生成笛卡尔积的表连接方式，返回左表每行与右表每行的所有组合，结果行数为两表行数乘积；其与逗号语法语义等价，但CROSS JOIN可读性更强、意图更清晰、更安全，且在搭配ON子句时会报错而逗号语法可能误将ON当作WHERE处理。
什么是 CROSS JOIN，它和逗号语法有什么区别？
CROSS JOIN 是 SQL 中明确表达笛卡尔积的语法，它把左表的每一行和右表的每一行配对组合。不加 WHERE 条件时，结果行数等于左表行数 × 右表行数。和老式逗号分隔写法（如 SELECT * FROM a, b）语义等价，但可读性更好、意图更清晰，也更容易被现代 SQL 分析器识别为显式连接。
- 显式写法更安全：避免意外遗漏
JOIN ... ON或WHERE导致隐式笛卡尔积 - 某些数据库（如 SQL Server）在启用 ANSI_WARNINGS 时会对逗号语法报警告
-
CROSS JOIN在复杂查询中更容易定位逻辑——一眼看出“这里就是要穷举”
怎么写一个带过滤条件的 CROSS JOIN？
CROSS JOIN 本身不支持 ON 子句，但你可以在 WHERE 中加条件来筛选结果。注意：这不是“优化执行”，而是先生成完整笛卡尔积再过滤，性能可能极差。
- 如果左右表分别有 1000 行，先生成 100 万行，再用
WHERE筛出 10 行，代价远高于用INNER JOIN+ON - 真正需要笛卡尔积时（比如生成所有日期+所有产品组合），才用
CROSS JOIN；否则优先考虑INNER JOIN或子查询 - 示例：生成 2024 年每天与三个销售区域的组合
SELECT d.date, r.region FROM (SELECT '2024-01-01'::DATE + generate_series(0,365) AS date) d CROSS JOIN (VALUES ('North'), ('South'), ('East')) AS r(region);
哪些场景下必须用 CROSS JOIN？
真正需要笛卡尔积的场景其实不多，但一旦需要，替代方案往往更啰嗦或不可靠：
- 构造测试数据：比如用
(VALUES (1),(2),(3))和(VALUES ('a'),('b'))快速生成 6 行组合 - 时间维度扩展：把一个日期列表和一组指标名做组合，用于后续 LEFT JOIN 填充空值
- 配置爆炸式展开：比如每个用户都要匹配每种通知模板，且无业务关联字段
- 注意：MySQL 5.7+ 对
CROSS JOIN有优化，但 PostgreSQL / SQL Server 仍按标准语义执行——先积后筛
为什么执行计划里看到 Hash Join 却写了 CROSS JOIN？
优化器有权重写连接方式。即使你写 CROSS JOIN，只要实际存在可利用的等值条件（比如隐含的主外键关系），某些数据库会把它转成 Hash Join 或 Nested Loop 执行，但结果集仍保持笛卡尔积语义——前提是没加 WHERE。
- 不要依赖执行计划判断是否真做了笛卡尔积；查
EXPLAIN ANALYZE的实际行数输出更可靠 - 如果发现
CROSS JOIN执行异常慢，第一反应不是换写法，而是确认左右表是否真的该这么连——90% 的“慢”源于误用而非语法本身 - 小心
NULL值：如果某表含大量NULL，而你又在WHERE里用了=判断，可能意外排除整块组合
笛卡尔积不是语法问题，是建模问题。写 CROSS JOIN 前，得确认「我确实需要所有组合」，而不是「我还没想清楚怎么关联」。
