cross join 专用于生成全组合枚举，而非基于字段匹配的连接；它不依赖on条件，语义明确表达“穷举所有配对”，适用于课程×学生、颜色×尺寸等场景，但易引发数据爆炸，需谨慎使用。
CROSS JOIN 适合生成全组合，不是为了“连接”而是为了“枚举”
当你需要穷举所有可能的配对关系（比如课程×学生、颜色×尺寸、日期×产品），而不是基于某列值匹配两表记录时，CROSS JOIN 是语义最直接、意图最清晰的选择。它不隐含任何过滤逻辑，也不依赖 ON 条件——这反而是优势。
常见错误现象：
- 用
INNER JOIN写成SELECT * FROM a INNER JOIN b（漏掉ON），结果看似和CROSS JOIN一样，但这是危险的误用：MySQL 会退化为笛卡尔积，而其他数据库（如 PostgreSQL）会报错； - 在报表中硬加
WHERE a.id = b.id到CROSS JOIN后，性能比直接写INNER JOIN ... ON更差，因为优化器无法提前剪枝。
使用场景：
- 构建维度组合表（例如：每日+每类产品 → 补全缺失销售记录）；
- 生成测试数据（如 100 个用户 × 50 个订单状态 = 5000 行模拟数据）；
- 时间序列填充（
dates表 ×products表 → 强制每个产品都有每天的占位行）。
参数差异与性能影响：
-
CROSS JOIN不接受ON子句，只能靠WHERE过滤，这意味着执行计划里先生成完整笛卡尔积再过滤，内存和临时空间压力大； -
INNER JOIN的ON条件可被索引利用，优化器能选择驱动表、下推条件、提前终止扫描； - 当两表分别有 10 万行时，
CROSS JOIN默认产生 100 亿行中间结果——哪怕最终WHERE只留下 100 行，也极可能 OOM 或超时。
什么时候必须用 CROSS JOIN 而不能用 INNER JOIN
当左表某行需要和右表**每一行**都配对，且这种配对不依赖任何字段相等性时，CROSS JOIN 是唯一自然表达该逻辑的方式。
例如：给每个用户分配一套默认权限（权限集固定，用户动态增减）：
SELECT u.user_id, p.permission_code FROM users u CROSS JOIN permissions p WHERE u.status = 'active';
这里 u.user_id 和 p.permission_code 之间没有关联字段，也不能写 ON 1=1 模拟——那属于滥用 INNER JOIN，语义模糊且部分数据库不支持。
MySQL 中 CROSS JOIN 和 INNER JOIN 看似等价，但行为边界很窄
在 MySQL 5.6+ 中，CROSS JOIN 和 INNER JOIN 在语法上允许互换，**仅当两者都不带 ON 或都带等效 WHERE 条件时才结果一致**。但这只是巧合，不是设计本意。
容易踩的坑：
- 跨数据库迁移时失效：SQL Server / PostgreSQL 不允许
INNER JOIN缺省ON，会报错； - 阅读者误判意图：看到
INNER JOIN就默认存在业务关联逻辑，实际却是枚举，造成理解偏差； - 优化器限制：MySQL 对
CROSS JOIN的重排策略更保守，有时无法像INNER JOIN那样自动交换表顺序来利用索引。
真正关键的不是“哪个更快”，而是“哪个更准确表达了你要做的事”。枚举就是枚举，匹配就是匹配——混用会让后续维护的人花三倍时间确认你当初到底想干什么。
