left join性能优化核心是调整连接顺序、强制右表索引、避免where过滤右表——应将结果集最小的表置左，右表on字段建复合索引，右表过滤条件须移入on子句。
为什么 JOIN 条件里不能只写 start_time
这种写法看似在“找重叠”，实际查出来的是笛卡尔积里的大部分无效组合。时间段重叠的数学定义是：A.start = B.start。漏掉任一条件，就会漏掉部分重叠（比如一个区间完全包住另一个），或引入不重叠的记录（比如仅端点相接但不算重叠，取决于业务定义）。
常见错误现象：
• 返回成千上万条记录，远超预期
• 同一条主表记录反复出现，每条都配了不同副表记录但其实没重叠
• 查询耗时陡增，执行计划显示全表扫描
- 务必同时检查两端：左区间的起点 ≤ 右区间的终点 且 左区间的终点 ≥ 右区间的起点
- 如果业务约定端点相接（如
2024-01-01 10:00和2024-01-01 10:00）不算重叠，把/<code>>=改成/<code>> - 字段类型必须一致——
start_time是DATETIME，end_time就不能是DATE，否则隐式转换可能使索引失效
如何给时间段字段加索引才真正生效
JOIN 走不上索引，往往不是语法问题，而是索引设计没对准查询模式。单列索引（如只建在 start_time 上）对重叠判断帮助极小，因为数据库无法用单一有序序列高效判断区间交叉。
使用场景：
• 表数据量 > 10k 行
• 查询频率较高，或需支持实时报表
- 优先建复合索引：
CREATE INDEX idx_period ON events (start_time, end_time)—— 这能让优化器在范围扫描时更早剪枝 - 某些数据库（如 PostgreSQL）支持专用的
RANGE类型和 GiST 索引，MySQL 8.0+ 可用函数索引模拟：CREATE INDEX idx_start_end ON t ((start_time), (end_time)) - 避免在
JOIN条件里对字段做计算，例如DATE(start_time)会令所有索引失效
LEFT JOIN + 重叠条件返回 NULL 怎么解释
当用 LEFT JOIN 查找“没有重叠的记录”时，很多人误以为只要 ON 条件写对就行，结果发现匹配行数远少于预期，甚至全为 NULL。根本原因是：SQL 标准规定，ON 子句在 LEFT JOIN 中只控制“匹配逻辑”，不改变左表行为；而重叠条件一旦不满足，右表字段就自然为 NULL，但这不代表左表记录本身有问题。
典型错误写法：SELECT a.* FROM orders a LEFT JOIN events b ON a.start = b.start WHERE b.id IS NULL
这语句本意是找“没被任何 event 覆盖的 order”，但若 events 表为空，b.id IS NULL 恒成立，结果会返回全部 orders —— 显然不合逻辑。
- 正确做法是用
NOT EXISTS替代：WHERE NOT EXISTS (SELECT 1 FROM events b WHERE a.start = b.start) - 如果坚持用
LEFT JOIN，必须确认右表有至少一条记录参与关联，否则IS NULL判断失去意义 - 注意
NULL值在时间字段中的含义：若end_time允许为NULL，需额外处理，例如COALESCE(b.end_time, '9999-12-31')
PostgreSQL 的 && 操作符真能简化写法吗
是的，但仅限于 tsrange 或 daterange 类型字段。直接对 TIMESTAMP 列用 && 会报错：operator does not exist: timestamp without time zone && timestamp without time zone。
性能影响：
• 使用 tsrange 配合 GiST 索引，重叠查询比传统双条件快 3–5 倍（实测百万级数据）
• 但类型转换有开销：每次查询都要 tsrange(start_time, end_time, '[)')
- 建表时就定义为范围类型最稳妥：
period tsrange，然后插入用tsrange('2024-01-01', '2024-01-05', '[)') - 现有表可加生成列（PostgreSQL 12+）：
ALTER TABLE t ADD COLUMN period tsrange GENERATED ALWAYS AS (tsrange(start_time, end_time, '[)')) STORED - 方括号语法很重要：
'[)'表示左闭右开，避免端点重复计算；用'[]'会包含右端点，和常规业务习惯可能不符
实际写这类查询时，最容易被忽略的是时间精度和时区。哪怕两个时间看起来相等，TIMESTAMP WITHOUT TIME ZONE 和 TIMESTAMP WITH TIME ZONE 在比较时会隐式转换，导致重叠判断失效。动手前先 SELECT pg_typeof(start_time) 确认类型，比调半天 SQL 更省时间。
