cross join是压力测试数据生成中唯一能稳定输出确定行数的笛卡尔积工具，但直接对users×orders等真实业务表使用会导致中间结果集爆炸、内存溢出或锁表阻塞；正确做法是用values或generate_series()构造轻量驱动表，避免触碰业务表。
CROSS JOIN 是压力测试数据生成中唯一能稳定输出确定行数的笛卡尔积工具，但直接对业务大表用它，90% 的情况会炸库或卡死。
为什么不能直接对 users × orders 写 CROSS JOIN
真实业务表往往带索引、约束、触发器，且行数不可控。一旦执行 SELECT * FROM users CROSS JOIN orders，数据库必须在内存中构建完整中间结果集——哪怕两表各 10 万行，结果就是 100 亿行，远超多数数据库默认 work_mem 或 temp_tablespaces 容量。
- MySQL 会报
ERROR 1114 (HY000): The table 'xxx' is full或直接 OOM kill 进程 - PostgreSQL 报
ERROR: out of memory或触发temp_file_limit中断 - SQL Server 可能卡在
WRITELOG等待，事务日志撑爆 - 即使跑通，后续 INSERT INTO ... SELECT 也会因锁表时间过长阻塞线上业务
正确做法：用 VALUES 或 generate_series() 构造轻量驱动表
核心原则是「不碰真实业务表，只用虚拟行构造维度」。VALUES 最通用，generate_series() 在 PostgreSQL 中更灵活。
- MySQL 8.0+ 支持裸
VALUES (1),(2),(3)；5.7 必须包装成(SELECT 1 AS n UNION ALL SELECT 2 UNION ALL SELECT 3) AS t - PostgreSQL 推荐用
generate_series(1, 100)替代长列表，避免 SQL 过长或解析失败 - SQL Server 必须写成
(VALUES (1), (2), (3)) AS t(n)，括号和别名缺一不可 - 所有 VALUES 子句中每行字段数、类型必须严格一致，否则报
column "x" has type text but expression has type integer
示例（PostgreSQL）：
SELECT u.id AS user_id, p.sku, d.date
FROM (SELECT * FROM generate_series(1, 100)) AS u(id)
CROSS JOIN (VALUES ('SKU-A'), ('SKU-B'), ('SKU-C')) AS p(sku)
CROSS JOIN (SELECT '2026-06-01'::DATE + n AS date FROM generate_series(0, 6) AS n) AS d(date);
如何控制最终数据量不越界
CROSS JOIN 行数 = 各驱动表行数乘积，这个数字增长极快。三张表分别 100、50、30 行，结果就是 15 万行；若误设为 1000、1000、1000，就是 10 亿行。
- 开发阶段必加
LIMIT 1000验证字段结构和类型，再删掉 - 生产压测前，先用
SELECT COUNT(*)分别查清每个驱动表行数，手动算乘积是否在预期范围内（建议单次 ≤ 50 万行） - 如需更大规模，拆成多批次 INSERT，例如按 user_id 范围分片：
WHERE u.id BETWEEN 1 AND 100 - 避免在 SELECT 中写计算逻辑（如
u.id * 1000 + p.id），可能引发隐式转换或重复求值，尤其在 MySQL 中易触发 full table scan
最容易被忽略的兼容性陷阱
不是所有数据库都把 CROSS JOIN 当作纯语法糖。SQLite 不支持裸 VALUES 作为表源，必须用 SELECT * FROM (VALUES ...) 包裹；而 MySQL 对 ON 子句的容忍度反而是个坑——写了 CROSS JOIN ... ON 1=1 不报错，但语义已退化为 INNER JOIN，结果行数可能少于预期。
真正难的不是写出能跑的 SQL，是判断“这个组合真的该全量生成吗”。比如压测下单链路，用户 × 商品 × 地区 × 时间点，看似要 4 维叉乘，但实际只需覆盖典型场景（如华东高并发时段+热门商品+新用户），这时用 VALUES 手动枚举 5~10 组关键组合，比盲目叉乘更高效、更可控。
