sql server中cross join必须显式书写，不支持from a, b隐式写法；其适用场景限于语义上天然全配对的表，且需警惕笛卡尔积膨胀风险，推荐用values构造轻量维度或先过滤再连接。
SQL Server里CROSS JOIN必须显式写出，不能省略关键字
SQL Server 不接受 FROM A, B 这种隐式写法来替代 CROSS JOIN；它会把逗号分隔当作语法错误，除非你明确加了 JOIN 关键字。也就是说，SELECT * FROM users, roles 会报错，而 SELECT * FROM users CROSS JOIN roles 才合法。
常见误操作是照搬 MySQL 写法，结果在 SQL Server 里直接失败。如果你从别处复制了带逗号的旧脚本，得手动补上 CROSS JOIN —— 不是风格问题，是语法硬性要求。
- ✅ 正确：
SELECT u.name, r.role_name FROM users u CROSS JOIN roles r - ❌ 报错：
SELECT u.name, r.role_name FROM users u, roles r - ⚠️ 注意：SQL Server 不支持
CROSS JOIN ON或CROSS JOIN USING，写了就 Syntax error
生成报表前先确认两表是否真“无关联”，否则容易产出脏数据
比如你有 products 表和 regions 表，表面看没外键，但业务上“某商品只在特定区域销售”——这时用 CROSS JOIN 会生成大量无效组合（如西藏特产出现在黑龙江门店），后续还得靠 WHERE 过滤，反而让执行计划先算出百万行再砍掉99%。
真正适合 CROSS JOIN 的场景是语义上“天然全配对”：权限模板 × 用户组、促销标签 × 商品类目、测试用城市 × 时间段。如果两表其实存在逻辑绑定关系，优先建视图或用 INNER JOIN ... ON 显式声明条件。
- ✔️ 合理：
SELECT u.id, p.perm_code FROM user_groups u CROSS JOIN permissions p（每个组默认拥有全部权限） - ✘ 危险：
SELECT o.order_id, s.store_name FROM orders o CROSS JOIN stores s（订单本就归属某门店，不该乱配） - ? 小技巧：用
EXISTS或LEFT JOIN先验证是否存在未覆盖的组合，比硬跑CROSS JOIN更稳妥
带 WHERE 的 CROSS JOIN 不是“优化”，而是先膨胀再过滤
CROSS JOIN 本身不支持 ON，但允许后面接 WHERE。问题是：数据库仍会先生成完整笛卡尔积，再应用过滤。例如 products（10万行）× regions（50行）= 500万行，哪怕 WHERE regions.country = 'CN' 最终只留10行，这500万行中间结果仍会走内存、占 tempdb、拖慢响应。
若目标只是“中国区商品清单”，更高效的方式是先 WHERE 缩小输入集，再连接：
- ❌ 低效：
SELECT p.name, r.city FROM products p CROSS JOIN regions r WHERE r.country = 'CN' - ✅ 更好：
SELECT p.name, r.city FROM products p CROSS JOIN (SELECT city FROM regions WHERE country = 'CN') r - ? 关键区别：子查询提前筛出行数，避免主表被无谓放大
构造报表时用 VALUES 驱动维度，避免依赖真实大表
直接对业务表做 CROSS JOIN 容易失控。生成报表常用做法是用轻量 VALUES 构造可控维度，再逐层交叉。SQL Server 支持 (VALUES (...)) AS alias(col) 语法，括号不能省。
例如要生成“Q1-Q4 × 北上广深 × 销售/运营/技术”共 4×4×3 = 48 条骨架记录：
SELECT q.quarter, c.city, d.dept
FROM (VALUES ('Q1'),('Q2'),('Q3'),('Q4')) AS q(quarter)
CROSS JOIN (VALUES ('北京'),('上海'),('广州'),('深圳')) AS c(city)
CROSS JOIN (VALUES ('销售'),('运营'),('技术')) AS d(dept);
这种写法不查任何业务表，执行快、结果稳、易调试。一旦某维度需要动态取值（如从 dim_date 查季度），再替换成子查询即可，结构不变。
注意：三张各 1000 行的表做 CROSS JOIN 会产出 10 亿行，SQL Server 很可能在返回前就因内存不足中断。单次组合建议控制在 100 万行以内，或加 TOP 100000 保底。
