非等值BETWEEN JOIN是用日期范围条件（如logs.timestamp BETWEEN events.start_time AND events.end_time）替代等值连接的JOIN，常用于日志归因等场景；MySQL 8.0.22前不支持该语法，且BETWEEN存在端点脏数据静默跳过问题，应改用显式比较。
什么是非等值BETWEEN JOIN？
它不是标准 SQL 的 JOIN ... ON a.id = b.id 这种等值连接，而是用日期范围条件做关联，比如：events.start_time = logs.timestamp。这类查询在日志归因、会话划分、事件覆盖分析中很常见，但容易写错或性能爆炸。
直接用 BETWEEN 写 JOIN 会出错吗？
会。很多人想当然写成 JOIN events ON logs.timestamp BETWEEN events.start_time AND events.end_time，语法上多数数据库（PostgreSQL、SQL Server）允许，但 MySQL 8.0.22 之前不支持 BETWEEN 在 ON 子句中作为布尔表达式（报错：ERROR 1064）。更关键的是：即使语法通过，语义也未必是你想要的——BETWEEN a AND b 要求 a ，如果表里存在 <code>start_time > end_time 的脏数据，整行会被静默跳过，且不报错。
- 推荐统一改用显式比较：
logs.timestamp >= events.start_time AND logs.timestamp - 加 WHERE 过滤掉无效区间：
WHERE events.start_time - 对
events.start_time和events.end_time建复合索引（顺序重要：先左边界，再右边界）
如何避免笛卡尔积和慢查询？
非等值 JOIN 天然容易触发嵌套循环，尤其当 events 表有 10 万行、logs 表有 50 万行时，暴力匹配可能扫描 50 亿次。优化核心是「缩小右表可匹配的候选集」：
- 给
logs.timestamp加索引（必须） - 把时间范围条件尽量“下推”到子查询或 CTE 中，例如先用
WHERE logs.timestamp BETWEEN (SELECT MIN(start_time) FROM events) AND (SELECT MAX(end_time) FROM events)预过滤 logs - PostgreSQL 可启用
enable_mergejoin = off强制走 Index Nested Loop；MySQL 8.0+ 可用/*+ USE_INDEX(events, idx_start_end) */提示优化器 - 如果业务允许近似结果，考虑将 logs 按小时/天分桶，用
DATE_TRUNC('day', timestamp)或DATE(timestamp)先粗粒度关联，再细筛
不同数据库对非等值 JOIN 的实际支持差异
别假设“标准 SQL 就该一样”。真实情况是：
- PostgreSQL：完全支持，且能利用
gist或spgist索引加速区间查询（如用tsrange类型 +gist索引） - MySQL：5.7 不支持非等值 JOIN 的索引下推，8.0 支持但需确保统计信息准确（
ANALYZE TABLE），否则仍走全表扫描 - BigQuery：支持，但
JOIN条件中不能含子查询；推荐改用ARRAY JOIN+UNNEST预展开 events 区间 - Spark SQL：支持，但需注意
shuffle开销极大，建议先用broadcast提示小表 events（/*+ BROADCAST(events) */）
最常被忽略的一点：时间字段的时区和精度。如果 logs.timestamp 是 TIMESTAMP WITH TIME ZONE，而 events.start_time 是 DATE，隐式转换会导致索引失效——务必统一类型和时区，必要时显式 AT TIME ZONE 或 CAST。
