能，非等值JOIN可直接使用>=、<=等比较运算符，如ON o.order_time >= p.start_time AND o.order_time <= p.end_time。
非等值 JOIN 能直接用 >=、、<code>BETWEEN 等条件，但写错位置或没索引，轻则慢十倍，重则查不出数据或 OOM。
ON 子句里写范围条件，别塞到 WHERE 里
很多人把区间逻辑丢进 WHERE，比如：
SELECT o.order_id, p.promo_name FROM orders o JOIN promotions p ON o.order_id = p.order_id WHERE o.order_time >= p.start_time AND o.order_time <= p.end_time;
这实际是先做等值 JOIN（可能空跑），再全量过滤——右表没被提前剪枝，优化器大概率放弃索引，变成嵌套循环扫全表。
- 正确做法：所有范围判断必须放在
ON子句中，让连接引擎在配对阶段就控制扫描范围 - LEFT JOIN 时尤其关键：WHERE 过滤右表字段会把左表无匹配行也干掉，等效变 INNER JOIN
- PostgreSQL 和 MySQL 8.0+ 都支持，但 MySQL 5.7 默认报错
ERROR 1054，执行前先查SELECT VERSION()
MySQL 8.0+ 必须加复合索引，否则性能断崖
只给 start_time 单独建索引没用。优化器无法用它高效处理 o.order_time >= p.start_time AND o.order_time 这类双边界条件。
- 建索引要按查询顺序来：
CREATE INDEX idx_range ON promotions (start_time, end_time) - 如果常按时间倒序取最近活动，可改成
(start_time DESC, end_time)，配合ORDER BY p.start_time DESC LIMIT 1 - 用
EXPLAIN看执行计划：如果type是ALL或index，说明没走范围扫描，索引无效
边界重叠或 NULL 导致漏匹配，得手动兜底
区间表里常见坑：两条记录分别是 min_amount=0, max_amount=100 和 min_amount=100, max_amount=200，金额刚好 100 时可能被两条都匹配，也可能一条都不中（取决于用 还是 <code>）。
- 统一用左闭右开：写成
o.amount >= p.min_amount AND o.amount ，再补一行 <code>max_amount IS NULL做兜底 - NULL 边界必须显式处理，否则整个条件短路：用
COALESCE(p.start_time, '1970-01-01')和COALESCE(p.end_time, '9999-12-31') - 时间字段优先用
TIMESTAMP WITH TIME ZONE，避免夏令时导致的 1 小时偏移引发区间错位
大表关联时结果爆炸，得加 LIMIT 或窗口函数控量
一个订单可能落在多个促销时段里，不做限制，1 万订单 × 平均 5 个匹配 = 5 万行；若右表有 100 万活动记录，最差情况直接笛卡尔积撑爆内存。
- PostgreSQL 用
LATERAL+LIMIT 1最稳：LEFT JOIN LATERAL (SELECT ... ORDER BY start_time DESC LIMIT 1) p ON true - MySQL 8.0+ 没
LATERAL，改用窗口函数：ROW_NUMBER() OVER (PARTITION BY o.order_id ORDER BY p.start_time DESC)，外层筛rn = 1 - 千万别信
OVERLAPS：仅 PostgreSQL 支持，不走索引，100 万行实测比手写a.start = b.start慢 8 倍
真正卡住的从来不是语法，而是索引是否覆盖查询模式、NULL 是否被显式处理、以及结果集是否被隐式放大——这三处不动手调，光改 ON 里的符号没用。
