cross join是唯一能先搭出完整维度骨架的操作，用于补全缺失统计单元，但需先收窄维度表再执行，避免内存爆炸和隐式笛卡尔积风险。
生成全量维度组合：补全缺失的统计单元
报表里经常要“显示所有日期 × 所有产品 × 所有门店”的销售额，哪怕某天某店没卖出去——这时候 CROSS JOIN 是唯一能先搭出完整骨架的操作。它不依赖业务数据是否存在，只负责把维度穷举出来。
- 必须先用 CTE 或子查询把维度表收窄（比如只取近30天、只取在售产品），再
CROSS JOIN，否则一不小心就爆内存 - 补全后要用
LEFT JOIN接真实销售表，CROSS JOIN本身不带任何业务逻辑，只是造壳 - Hive 和 Spark SQL 对大表
CROSS JOIN会报Cartesian product not allowed错误，得提前加SET hive.mapred.mode=nonstrict;或改用广播小表
构造辅助序列：比如每月/每周/每小时的基准时间点
想给每个用户打上“2024年1月到12月”的标签，或者为每个设备生成“过去7天每天一条记录”，靠 JOIN 没法凭空造时间，只能靠 CROSS JOIN 把静态序列和主表拼起来。
- 序列建议用递归 CTE（MySQL 8.0+ / PostgreSQL）或
VALUES构造（SQL Server / Hive），避免用SELECT 0 UNION SELECT 1 ...写十几行 - SQL Server 中如果序列超过 100 行，建议用
master..spt_values或数字表，否则执行计划会退化成 Nested Loops - 别在
CROSS JOIN后加WHERE过滤日期范围——那等于先算完笛卡尔积再筛，应该把过滤写在序列子查询里
测试数据快速生成：绕过 INSERT 循环的暴力方案
压测需要 100 万条订单模拟数据，但又不想写脚本？用两个小表 CROSS JOIN 就能指数级放大：1000 用户 × 1000 商品 = 100 万组合。
- 字段要加随机化处理，比如
ABS(CHECKSUM(NEWID())) % 100模拟金额，否则全是重复值 - MySQL 里
CROSS JOIN和INNER JOIN在无ON条件时行为一致，但语义模糊，生产环境必须显式写CROSS JOIN - 生成后立刻加
INSERT INTO ... SELECT，别直接查——结果集太大时客户端可能断连或 OOM
真正危险的不是 CROSS JOIN，而是没意识到它在哪儿
很多慢查询其实暗藏了隐式笛卡尔积：比如 SELECT * FROM a, b WHERE a.id = b.pid 看似是内连接，但如果 b.pid 全是 NULL，就会退化成全表交叉；又或者 ON 条件写成 a.x b.y，某些引擎也会触发笛卡尔逻辑。这些比明写 CROSS JOIN 更难排查。
