JOIN不生成随机数据，仅关联已有记录；构建测试数据需先有基础表，再通过JOIN组合，配合ORDER BY RANDOM()、CROSS JOIN VALUES或generate_series()等方法控制数量与维度。
JOIN 本身不生成随机数据，但能高效组装已有测试表
SQL 的 JOIN 是关联已有记录的工具，不是随机数生成器。想“快速构建测试数据”，得先有基础表（比如用户、订单、商品），再用 JOIN 把它们按逻辑拼起来——比如给每个用户配 3 条随机订单，本质是靠笛卡尔积 + LIMIT 或 ORDER BY RANDOM() 控制数量，而不是 JOIN 自己造数据。
常见错误现象：SELECT * FROM users JOIN orders 没加 ON 条件，结果爆炸式膨胀（100 用户 × 1000 订单 = 10 万行），还以为“生成成功”了。
- 必须显式写
ON或USING，哪怕只是ON true（慎用） - 若真要“随机组合”，优先在子查询里先用
ORDER BY RANDOM() LIMIT N限定右表数据量 - PostgreSQL 支持
TABLESAMPLE SYSTEM (5)快速抽样，MySQL 8.0+ 可用ROW_NUMBER() OVER() % 5 = 0模拟
用 CROSS JOIN + VALUES 构造小规模组合测试集
当需要固定几组“典型场景”（比如不同状态 × 不同地区 × 不同金额区间），CROSS JOIN 配合 VALUES 最直接。它不依赖现有表，适合初始化测试环境。
使用场景：验证报表 SQL 在「华东-已支付-¥100~500」这类组合下的输出是否正确。
SELECT region, status, amount_range
FROM (VALUES ('华北'), ('华东'), ('华南')) AS t1(region)
CROSS JOIN (VALUES ('待付款'), ('已支付'), ('已退款')) AS t2(status)
CROSS JOIN (VALUES ('¥0~99'), ('¥100~499'), ('¥500+')) AS t3(amount_range);-
VALUES每组括号内必须字段数、类型一致，否则报错column "x" has type text but expression has type integer - 三张
VALUES表做CROSS JOIN，结果行数是各表行数乘积（3×3×3=27），别无脑套用到大表上 - SQLite 不支持
VALUES单独作为表源，得包装成SELECT * FROM (VALUES ...)
LEFT JOIN 配合 generate_series() 填充缺失时间维度（PostgreSQL）
测试时间序列分析时，常需“补全日期”——比如查 7 天内每天订单数，但某天没订单，结果就少一行。用 generate_series() 生成日期，再 LEFT JOIN 订单表，就能强制返回 7 行。
性能影响：生成 1 年日期（365 行）几乎无压力；生成 10 年（3650 行）仍可接受；但 generate_series(1, 1000000) 就会卡住，别这么干。
SELECT d.day::date, COUNT(o.id)
FROM generate_series('2024-01-01'::date, '2024-01-07'::date, '1 day') AS d(day)
LEFT JOIN orders o ON DATE(o.created_at) = d.day
GROUP BY d.day
ORDER BY d.day;- MySQL / SQLite 没
generate_series()，得用递归 CTE（MySQL 8.0+）或临时数字表模拟 -
LEFT JOIN后记得用COUNT(o.id)而非COUNT(*)，否则空行也计为 1 - 注意时区：如果
created_at是timestamptz，用DATE(created_at AT TIME ZONE 'Asia/Shanghai')对齐
INSERT ... SELECT + JOIN 实现批量测试数据注入
真正把组合结果存成新测试表，靠 INSERT INTO target_table SELECT ... FROM ... JOIN ...。这是最接近“构建”的一步，但前提是源表数据可控。
容易踩的坑：INSERT 时字段顺序和目标表定义不一致，或类型隐式转换失败（比如把字符串 'null' 插进 INT 字段）。
- 务必显式写出
INSERT INTO t(a,b,c) SELECT x,y,z FROM ...，别依赖列序匹配 - 若源字段可能为
NULL，而目标列是NOT NULL，提前用COALESCE(col, 0)或CASE WHEN处理 - 大表 JOIN 后插入前，先
EXPLAIN ANALYZE看执行计划，避免走嵌套循环（Nested Loop）拖垮性能
复杂点在于：你得先确保“基础测试表”里的数据分布合理——比如用户表里性别比例、地域分布是否贴近真实，否则 JOIN 出来的“测试数据”再快也没意义。
