该用CROSS JOIN而非INNER JOIN时：需穷举所有组合（如“所有门店×所有商品”）且无关联字段；INNER JOIN加空条件语义模糊、部分数据库报错，而CROSS JOIN语法明确、执行计划清晰标识笛卡尔积。
什么时候该用 CROSS JOIN 而不是 INNER JOIN
当你需要穷举所有可能的组合（比如「所有门店 × 所有商品」），且业务逻辑上本就不依赖关联字段时，CROSS JOIN 是唯一合理选择。用 INNER JOIN 加空条件（如 ON 1=1）虽能凑出笛卡尔积，但语义模糊、可读性差，部分数据库（如 PostgreSQL）甚至会报错或拒绝执行。
常见错误现象：INNER JOIN ... ON true 在 Presto/Trino 中报 SyntaxError: unexpected token 'true'；MySQL 8.0+ 对 ON 1=1 会警告“non-equality join condition”，并可能触发全表扫描警告。
- 真实场景：排查促销活动中「未配置折扣的门店-商品对」，需先生成全量组合，再左连实际配置表找出缺失项
-
CROSS JOIN不写ON子句，语法干净，执行计划里明确标记为「Cartesian product」，便于 DBA 审计 - 性能影响显著：1000 行 × 500 行 = 50 万行结果，务必加
WHERE或提前LIMIT测试，否则拖垮查询
如何用 CROSS JOIN + LEFT JOIN 找出遗漏组合
核心思路是：先用 CROSS JOIN 构建理论全集，再用 LEFT JOIN 关联实际数据，筛选右表为 NULL 的行 —— 这些就是业务上“该有但没配”的组合。
示例（查未配置库存预警的商品-仓库对）：
SELECT w.warehouse_id, i.item_id FROM warehouses w CROSS JOIN items i LEFT JOIN inventory_alerts a ON a.warehouse_id = w.warehouse_id AND a.item_id = i.item_id WHERE a.warehouse_id IS NULL;
- 注意
LEFT JOIN的ON条件必须包含两张驱动表的主键，不能漏掉任一字段，否则会放大结果集 - 如果
inventory_alerts表有复合主键但缺失索引，这个查询会极慢；建议在(warehouse_id, item_id)上建联合索引 - 某些场景需排除无效组合（如已下架商品），应在
CROSS JOIN后立即用WHERE过滤，而不是塞进LEFT JOIN的ON里——后者会导致逻辑错误
CROSS JOIN 在不同数据库中的行为差异
MySQL 和 SQL Server 默认允许隐式 CROSS JOIN（逗号分隔表名），但 PostgreSQL 和 BigQuery 强制要求显式写 CROSS JOIN 关键字，否则报错 syntax error at or near ","。
- MySQL 5.7+：支持
SELECT * FROM t1, t2，但开启ONLY_FULL_GROUP_BY模式后可能报错，建议统一用显式语法 - BigQuery：不支持隐式笛卡尔积，必须写
CROSS JOIN；且对超大表会直接拒绝执行（如单表 >1TB），需先采样或加分区过滤 - Oracle：需用
CROSS JOIN，旧版用SELECT * FROM t1, t2 WHERE 1=1会被优化器转成哈希连接，不一定保证笛卡尔语义
为什么加了 WHERE 还查出 0 行？检查这三点
笛卡尔积排查最常卡在「明明该有遗漏却返回空」，根本原因往往不是语法错，而是数据状态被忽略。
- 其中一张表为空：只要
warehouses或items任一表无数据，CROSS JOIN结果就是空 —— 先单独SELECT COUNT(*)确认两表都有数据 - 关联字段类型不一致：比如
warehouse_id在warehouses是INT，在inventory_alerts是VARCHAR，导致LEFT JOIN匹配失败，IS NULL判定永远为真，结果膨胀而非为空 —— 查pg_typeof()或DESCRIBE核对类型 -
NULL值干扰：若items表中item_id允许NULL，CROSS JOIN会生成含NULL的组合行，而LEFT JOIN无法匹配NULL（SQL 中NULL = NULL为UNKNOWN），这些行也会进入结果，造成误判 —— 用WHERE i.item_id IS NOT NULL显式过滤
笛卡尔积本身不难写，难的是想清楚哪些组合在业务上“应该存在”。漏掉一个有效约束条件，结果就既不全也不准。
