CROSS JOIN 仅在需“每个A行配每个B行”时使用，如生成测试数据或配置组合；误用会导致笛卡尔积爆炸，应优先用 INNER JOIN 或 LATERAL 替代。
CROSS JOIN 会无条件组合两个表的所有行，不加 WHERE 就等于强制笛卡尔积——但多数业务场景下这不是你真正想要的，得先确认是否漏了关联条件或误用了 JOIN 类型。
什么时候该用 CROSS JOIN 而不是 INNER JOIN
只有当明确需要“每个 A 行配每个 B 行”时才用 CROSS JOIN，比如生成测试数据、枚举所有配置组合、构建时间维度模板。如果表 A 有 100 行、表 B 有 50 行，结果就是 5000 行——没加过滤就直接执行，很容易拖垮查询或爆内存。
- 常见误用：把本该写
ON a.id = b.a_id的INNER JOIN错写成CROSS JOIN，结果返回百万级无关记录 - 正确场景举例：给每个
product行配上全年 12 个月（months表只含 1–12），生成月度预测基线 - 替代写法：某些数据库支持
SELECT * FROM a, b（隐式笛卡尔积），但可读性差，不推荐
CROSS JOIN 没有 ON 子句，也不能加 WHERE 来模拟关联
加 WHERE 过滤后，语义上已不是笛卡尔积，而是带条件的联查，此时应改用 INNER JOIN ... ON。否则容易误导后续维护者，也影响优化器选择执行计划。
- 错误示范：
SELECT * FROM users CROSS JOIN orders WHERE users.id = orders.user_id→ 实际等价于INNER JOIN，但写法模糊且无法利用索引提示 - 性能影响：
CROSS JOIN会先算完全部组合再过滤，而INNER JOIN可基于连接键提前剪枝 - 部分数据库（如 PostgreSQL）对
CROSS JOIN ... WHERE会重写为JOIN，但 MySQL 8.0 前可能真按笛卡尔积执行
用 LATERAL 或子查询替代暴力 CROSS JOIN 的场景
当一侧行数动态变化（比如 JSON 数组展开、窗口函数结果），硬套 CROSS JOIN 会导致重复或漏数据，这时应优先考虑 LATERAL（PostgreSQL / SQL Server）或相关子查询。
- 例如：每个订单要拆成多行“商品 × 仓库”，而仓库列表存在
order行的 JSON 字段里——不能靠CROSS JOIN warehouses，得用LATERAL json_array_elements(order.warehouses) - MySQL 用户可用
JOIN ... ON 1=1模拟CROSS JOIN，但同样不解决动态右表问题 - 注意：SQLite 不支持
LATERAL，需用UNION ALL拆解或应用层处理
真正需要笛卡尔积时，务必检查左右表的数据量级；一旦某张表行数超过千级，就要警惕结果集爆炸——这时候往往不是 SQL 写错了，而是需求本身该用分组聚合、预计算表或应用层循环来解。
