必须用cross join而非逗号连接的场景是明确表达无条件全组合意图时，因其更安全、可读性强，且避免on子句误判；搭配on/using会报错，而逗号语法会错误地将on当作where处理。
什么时候必须用 CROSS JOIN，而不是逗号连接表
MySQL 中 CROSS JOIN 和隐式逗号连接（FROM t1, t2）在语义上等价，但行为有关键差异：当搭配 ON 或 USING 子句时，CROSS JOIN 会直接报错，而逗号语法不会——它会把 ON 当成 WHERE 条件处理，极易引发误判。
- 明确表达「无条件全组合」意图时，用
CROSS JOIN更安全、可读性更强 - 想写
CROSS JOIN ... ON ...？别试了，MySQL 会抛出ERROR 1064，这是语法硬限制 - 如果后续可能加
JOIN类型（比如改成LEFT JOIN），统一用显式JOIN语法能避免混用风格导致的逻辑混乱
CROSS JOIN 的实际用途远不止“生成所有组合”
纯笛卡尔积在业务中极少直接使用，但它是解决几类典型问题的底层工具：枚举补全、参数网格、时间序列对齐。关键不在于“有多少行”，而在于“缺什么行”。
- 补全缺失维度：比如统计每个部门 × 每个月的销售额，即使某部门某月没数据，也要显示 0 —— 先
CROSS JOIN部门表和月份表，再LEFT JOIN实际销售记录 - 生成测试数据：快速构造
n × m条模拟记录，比循环插入快得多，适合初始化或压测 - 避免子查询嵌套：某些场景下，用
CROSS JOIN+WHERE比多层SELECT ... FROM (SELECT ...) AS t1, (SELECT ...) AS t2更易读、优化器也更可能走索引
性能崩掉前你得知道的三个事实
CROSS JOIN 不触发索引，结果集大小是两表行数乘积，哪怕只是 1000 × 1000，也是百万级结果。很多慢查根源就在这里，而且错误往往藏在 JOIN 链后段。
- 没有
WHERE过滤的CROSS JOIN是危险信号，执行前务必EXPLAIN看rows估算值 - 如果其中一张表是派生表（
(SELECT ...)），MySQL 可能无法提前物化，导致重复计算，比预期更慢 - 5.7+ 版本对
CROSS JOIN无特殊优化，别指望它比逗号语法快；8.0 的哈希连接只适用于等值JOIN，对CROSS JOIN无效
一个常被忽略的兼容性坑：STRAIGHT_JOIN 不能和 CROSS JOIN 共存
想强制 MySQL 按指定顺序读表？STRAIGHT_JOIN 在 CROSS JOIN 场景下完全失效——它只作用于带 ON 条件的 JOIN，而 CROSS JOIN 天然无条件。
- 试图写
SELECT STRAIGHT_JOIN * FROM t1 CROSS JOIN t2？语法合法，但STRAIGHT_JOIN被忽略，优化器仍可能先扫大表 - 真要控制顺序，只能改用逗号语法：
SELECT STRAIGHT_JOIN * FROM t1, t2，此时t1会被优先访问 - 如果两张表都有索引且需过滤，不如拆成子查询 +
CROSS JOIN，把过滤下推到子查询里，比依赖STRAIGHT_JOIN更可靠
事情说清了就结束。真正难的不是写出 CROSS JOIN，而是判断它是不是当前问题的最小必要解——多数时候，你真正需要的是一张预计算的维度表，或者一个带 COALESCE 的 LEFT JOIN。
