直接用ON t1.time BETWEEN t2.start_time AND t2.end_time性能差，因多数数据库无法高效利用索引，易触发全表嵌套循环扫描，且区间重叠会导致结果集膨胀；应建独立单列索引、改用>=和
为什么直接用 ON t1.time BETWEEN t2.start_time AND t2.end_time 会慢得离谱
这种写法看似直观，但绝大多数数据库（MySQL 5.7/8.0、PostgreSQL 12+、SQL Server）无法对 BETWEEN 范围条件有效使用索引，尤其当 t2 表很大时，执行计划常退化为嵌套循环全表扫描。更糟的是，如果 t2 中存在大量重叠区间，还可能产生重复匹配行，结果集膨胀远超预期。
实操建议：
- 确保
t2.start_time和t2.end_time各自建单列索引（不是联合索引）——某些引擎（如 PostgreSQL）能利用两个独立索引做位图合并 - 加
AND t2.start_time = t1.time替代BETWEEN，语义一致但部分优化器识别更稳定 - 若
t2区间固定且数量少（如几百条），可先用子查询或 CTE 预过滤出可能覆盖的候选区间段，再 JOIN
用 LATERAL（PostgreSQL）或 APPLY（SQL Server）做左关联 + 限 1 来避免重复
当一条 t1 记录可能落在多个区间内，而你只想要“最先匹配”或“最精确匹配”的那条（比如取重叠区间中持续时间最短的），硬 JOIN 会爆炸式膨胀。这时候需要把右表匹配逻辑下推到每行左表数据上，并限制返回 1 行。
PostgreSQL 示例：
SELECT t1.id, t1.event_time, i.name, i.priority
FROM events t1
LEFT JOIN LATERAL (
SELECT name, priority
FROM intervals i
WHERE t1.event_time >= i.start_time
AND t1.event_time <= i.end_time
ORDER BY i.end_time - i.start_time ASC
LIMIT 1
) AS i ON true;SQL Server 等价写法用 OUTER APPLY，MySQL 8.0.14+ 可用 LATERAL，但注意 MySQL 对子查询中索引下推支持较弱，务必检查执行计划是否走了 i.start_time 和 i.end_time 索引。
MySQL 5.7 怎么绕过没有 LATERAL 的限制
MySQL 5.7 不支持 LATERAL，也不能在 ON 子句里写子查询。常见错误是试图用相关子查询塞进 SELECT 列表，导致 N+1 查询或 NULL 值漏匹配。
可行方案：
- 用
JOIN ... ON先粗筛：仅用t2.start_time 做等值/范围驱动，再在 <code>WHERE加t2.end_time >= t1.time过滤 —— 至少让索引能用上左边界 - 对结果集用变量模拟 rank：按
t1.id分组，按区间宽度排序后取@rn := IF(@prev = t1.id, @rn + 1, 1)，再外层WHERE rn = 1 - 如果区间可预处理成不重叠、左闭右开（
[start, end)），可用(t1.time - t2.start_time) >= 0 AND (t1.time - t2.start_time) ，有时能触发更好的索引选择
别忽略时区和精度问题：DATETIME vs TIMESTAMP vs microsecond
一旦涉及跨系统时间比对（比如日志表用 TIMESTAMP 存 UTC，配置表用 DATETIME 存本地时间），JOIN 匹配会静默失败。错误现象常是“明明时间在范围内却查不到”。
关键检查点：
- 确认两边字段是否同为
TIMESTAMP（自动转时区）或同为DATETIME（无时区）；混用必出错 - 如果时间精度到毫秒或微秒（如
DATETIME(6)），MySQL 在比较时可能因隐式截断丢精度，显式用CAST(t1.time AS DATETIME(6))对齐 - PostgreSQL 中
tsrange类型配合@>操作符更安全，但需确保所有时间已转为同一时区的TIMESTAMPTZ
范围匹配不是语法问题，是数据分布、索引策略和时序语义的叠加体。最容易被跳过的，其实是确认区间端点是否包含边界 —— 很多业务逻辑默认左闭右开，但字段存的却是左闭右闭，一不留神就漏掉临界点那条记录。
