CROSS JOIN 是构造测试数据最直接的工具，因其本质是无条件笛卡尔积，不依赖关联字段、无需 ON 条件、不隐式过滤，仅做纯粹行乘法，执行稳定、结果可预测，特别适合一次性生成海量组合型测试数据。
为什么 CROSS JOIN 是构造测试数据最直接的工具
CROSS JOIN 本质就是笛卡尔积，不需要 ON 条件，也不依赖字段关联逻辑——这恰恰是生成海量组合型测试数据的核心优势。它不筛选、不过滤、不隐式转换，只做纯粹的行乘法，因此执行稳定、结果可预测，特别适合压力测试前的数据铺底。
常见误用是把它和 INNER JOIN 混用，或者加了 WHERE 后还误以为是“纯笛卡尔”，其实只要带条件，就不再是严格意义上的笛卡尔集，性能模型和行数预期都会偏移。
CROSS JOIN 构造多维测试数据的三步写法
典型场景：为订单系统压测，需生成 100 个用户 × 50 种商品 × 30 个地区 = 15 万条模拟订单记录。不能靠循环插入，得用 SQL 一次性产出。
- 先建轻量级驱动表：用
VALUES或generate_series()（PostgreSQL）/numbers table（SQL Server）构造编号序列，避免依赖真实业务表 - 再逐层
CROSS JOIN：每张驱动表代表一个维度（如用户 ID、SKU 编号、城市编码），注意顺序不影响结果行数，但影响字段可读性 - 最后用
SELECT组装字段：所有列都来自各驱动表别名，禁止在SELECT中写计算逻辑（如id + 1），否则可能触发重复计算或隐式类型转换
示例（PostgreSQL）：
SELECT u.uid, s.sku, l.loc
FROM (VALUES (1),(2),(3),...,(100)) AS u(uid)
CROSS JOIN (VALUES ('A001'),('B002'),...,('Z050')) AS s(sku)
CROSS JOIN (VALUES ('BJ'),('SH'),('GZ'),...,('HZ')) AS l(loc);
MySQL / SQL Server / PostgreSQL 在 CROSS JOIN 上的关键差异
语法表面一致，但底层行为和限制不同，直接影响是否能跑通：
- MySQL 8.0+ 支持
VALUES表达式直接参与CROSS JOIN；5.7 及以前必须用SELECT包裹，例如(SELECT 1 AS n UNION ALL SELECT 2) AS t - SQL Server 不支持裸
VALUES作为表源，必须写成(VALUES (1),(2)) AS t(n)，且括号不能省 - PostgreSQL 对
VALUES最友好，但要注意：若某VALUES行含NULL，而另一张表有NOT NULL字段，CROSS JOIN仍会执行成功——因为笛卡尔积不校验约束
性能提示：三张各 1000 行的表做 CROSS JOIN，结果是 10 亿行。多数数据库会在内存撑爆前报错，建议单次不超过 100 万行，或用 LIMIT / TOP 控制输出规模。
避免“假笛卡尔”：那些看似 CROSS JOIN 实则失效的写法
实际中常因疏忽引入隐式过滤，导致行数远低于预期，压测数据稀疏、覆盖不全：
- 在
FROM子句用了CROSS JOIN，但WHERE里写了a.id = b.id—— 这已退化为等值INNER JOIN，不是笛卡尔 - 用视图或 CTE 做驱动表，而该视图内部含
GROUP BY或DISTINCT，导致行数被压缩，但你没意识到 - 字段类型不一致引发隐式转换，比如
user_id INT和sku_id VARCHAR在CROSS JOIN后虽不报错，但后续插入目标表时可能因类型不匹配失败
验证是否真笛卡尔：对结果执行 COUNT(*)，并手动计算各驱动表 COUNT(*) 的乘积，两者必须完全相等。差哪怕一行，说明中间有隐式裁剪。
真正难的不是写出 CROSS JOIN，而是确保每张驱动表的行集合干净、独立、无隐藏逻辑。压测数据失真，往往就失在这一步。
