cross join 返回两表笛卡尔积，行数为两表行数乘积，无连接条件，不用于关联数据；误用会导致结果集爆炸，仅适用于明确需要全组合的场景。
CROSS JOIN 会无条件组合两个表的每一行，结果行数是两表行数的乘积，不是“关联”，也没有 ON 条件——这点和 INNER JOIN 完全不同，误用会导致数据爆炸。
为什么 CROSS JOIN 返回的行数远超预期
常见错误是把 CROSS JOIN 当成“没写 ON 的 JOIN”来用，比如想查用户和订单的对应关系却写了 CROSS JOIN，结果每个用户都和每张订单配对一次。实际场景中，除非明确需要全排列（如生成测试数据、枚举所有组合），否则几乎不该用它。
- 表 A 有 100 行，表 B 有 50 行 →
CROSS JOIN结果是 5000 行 - 若其中一张表是动态增长的（比如日志表），笛卡尔积可能瞬间撑爆内存或超时
- SQL Server 不会对
CROSS JOIN做任何谓词下推优化，执行计划里就是 Nested Loops + “无关联”标识
CROSS JOIN 的合法使用场景和写法
真正需要笛卡尔积的场景有限，典型的是构造辅助数据集：比如给每个产品生成未来 12 个月的预测行，或为每个地区搭配所有产品类型。
- 语法必须显式写
CROSS JOIN，不能省略关键字（SELECT * FROM A, B是旧式隐式写法，不推荐，且容易和逗号 JOIN 混淆） - 不能带
ON或WHERE条件——如果加了过滤，就该考虑是否本意是INNER JOIN - 示例：生成 2024 年每月日期（用 CTE 构造月份表）与 3 个销售区域的组合
WITH months AS ( SELECT 1 AS m UNION ALL SELECT 2 UNION ALL SELECT 3 ) SELECT r.region_name, m.m AS month_num FROM regions r CROSS JOIN months m;
替代方案：什么时候该用 CROSS APPLY 而不是 CROSS JOIN
当右侧数据需要依赖左侧某一行动态生成时（比如对每个用户取其最近 3 条订单），CROSS JOIN 无能为力，必须用 CROSS APPLY。
-
CROSS JOIN是静态全连接；CROSS APPLY是每行调用一次子查询，支持相关引用 - 例如：
SELECT u.name, o.order_id FROM users u CROSS APPLY (SELECT TOP 3 * FROM orders WHERE user_id = u.id ORDER BY created_at DESC) o - 强行用
CROSS JOIN实现类似逻辑，得先做窗口函数预计算再连接，更复杂且难维护
性能和可读性陷阱
即使业务上真需要笛卡尔积，也要警惕 SQL Server 对大表的处理能力。10 万 × 10 万 = 100 亿行，磁盘和内存都扛不住。
- 务必在
CROSS JOIN前用WHERE或 CTE 先过滤左右表（但注意：过滤必须写在 JOIN 前，不是加在 JOIN 后的 WHERE） - 避免在视图或函数里封装
CROSS JOIN，调用方很难意识到底层有爆炸风险 - 如果只是临时生成组合用于 INSERT，优先考虑用应用层循环或
VALUES列表，比数据库级笛卡尔积更可控
笛卡尔积本身没有错，错的是把它当成通用连接手段。只要看到 CROSS JOIN，第一反应应该是：“这个结果集大小我能接受吗？有没有更窄的业务约束被漏掉了？”
