直接用 != 或 <> 做 JOIN 无法查区间，因为非等值 JOIN（如 >=、BETWEEN）不表示“排除相等”，而是需显式定义时间范围关系；MySQL 对其优化弱，易全表扫描，须配合索引、生成列或 STRAIGHT_JOIN 控制顺序。
为什么直接用 != 或
因为不等值 JOIN 不是“排除相等”，而是指 JOIN 条件中包含非等号比较（如 BETWEEN、>=、、<code>BETWEEN AND），用于匹配落在某个范围内的记录。很多人误以为 ON a.id != b.id 就能查“区间”，结果发现要么笛卡尔爆炸，要么逻辑完全不对——那只是排除自身，和区间无关。
真正查区间（比如“订单时间落在某促销时段内”“IP地址属于某网段”）必须用范围条件驱动 JOIN，且需注意索引失效风险。
-
JOIN ... ON t1.start_time = t2.event_time是典型区间匹配写法 - MySQL 8.0+、PostgreSQL、SQL Server 都支持，但 SQLite 不支持非等值 JOIN 的索引优化（会全表扫描）
- 如果任一 JOIN 字段为
NULL，整个条件为UNKNOWN，该行被过滤（注意空值陷阱）
怎么写才能避免性能崩掉？
区间 JOIN 极易触发嵌套循环（Nested Loop），尤其当两个表都很大时。关键不是“能不能写出来”，而是“能不能快”。最有效的约束手段是先做等值过滤再扩范围。
- 给范围字段建复合索引：例如
CREATE INDEX idx_events_time ON events(event_time)，再配合promo_periods(start_time, end_time) - 优先在小表（如促销期表只有几十行）上驱动 JOIN，避免用大表（如亿级订单表）作为左表去扫小表的每个区间
- 加显式限制：比如
AND t2.event_time >= '2024-01-01'，让优化器能利用时间分区或索引下界 - PostgreSQL 可用
RANGE类型 +OVERLAPS简化写法：ON (t1.period) OVERLAPS (t2.period)，语义清晰且可能走 GiST 索引
遇到重复匹配怎么办？一个事件落在多个区间里
这是区间 JOIN 的天然副作用。比如用户下单时间同时命中“春节活动”和“满减叠加活动”，默认会返回两条记录。是否去重取决于业务逻辑，不能靠 DISTINCT 盲目解决——它可能掩盖数据问题。
- 用
ROW_NUMBER() OVER (PARTITION BY t2.id ORDER BY t1.priority DESC)取最高优先级区间 - 改用
LATERAL（PostgreSQL/SQL Server）或APPLY（SQL Server）做 Top-1 关联，避免膨胀 - MySQL 8.0+ 可用
LEFT JOIN ... ON ... AND ...+WHERE t1.id IS NOT NULL模拟半连接，但需确保子查询能关联到单条 - 如果业务只要“是否命中任意区间”，改用
EXISTS更高效：WHERE EXISTS (SELECT 1 FROM periods p WHERE p.start = o.time)
MySQL 中写区间 JOIN 要特别注意什么？
MySQL 对非等值 JOIN 的优化能力较弱，5.7 和 8.0 行为差异大，容易踩坑。
- 5.7 不支持在
ON子句中对右表字段使用函数（如DATE(t2.created_at)），否则直接报错或退化为全表扫描 - 8.0 允许，但
CAST(t2.ts AS DATE)仍会导致索引失效；应提前在右表加生成列并建索引：ALTER TABLE events ADD COLUMN event_date DATE AS (DATE(created_at)) STORED - 如果区间表有重叠（比如两个促销时段时间交叉），MySQL 不会自动合并，需业务层判断是否允许多匹配
-
STRAIGHT_JOIN强制连接顺序有时能救性能，但必须确认小表确实在前：SELECT /*+ STRAIGHT_JOIN */ ... FROM small_periods p JOIN large_orders o ON ...
区间 JOIN 的核心不是语法多炫酷，而是清楚每行数据从哪来、为什么匹配、有没有被漏掉或重复——边界条件、空值、时区、索引覆盖，哪个没对齐，结果就不可信。
