时间重叠查询应避免$or+$and及空间索引，改用start单字段索引+应用层剪枝，配合$expr在$match中实现高效过滤，并注意时区、数据类型与状态筛选。
用 $or 拼多个 $and 时间范围查重叠，性能会崩
直接写 { $or: [ { start: { $lte: endInput }, end: { $gte: startInput } }, ... ] } 看似直观，但 MongoDB 无法有效走索引——哪怕你对 start 和 end 都建了复合索引。B-tree 索引不擅长“区间重叠”这种双向约束，查询时容易全表扫。
实操建议：
- 改用「端点归一化 + 排序 + 单字段索引」：把每个时间段拆成两个事件（
{ time: start, type: "open" }和{ time: end, type: "close" }），存进单独集合，按time建升序索引 - 查某段时间
[t1, t2]内有重叠的文档？只需查time ≤ t2且type = "open"的事件，再关联原文档，用$lookup或应用层 join - 避免在同一个文档里存多组时间字段（如
periods: [{start:..., end:...}, ...]），MongoDB 无法对数组内嵌对象做高效重叠判断
别硬套空间索引查时间重叠——2dsphere 不是万能胶
有人想把时间转成经纬度、用 2dsphere 索引跑多边形交集，这是典型误用。GeoJSON 的 Polygon 是二维欧氏空间，而时间线是一维有序域；强行映射会导致边界扭曲、精度丢失，且 $geoIntersects 对非地理语义的数据无业务意义。
常见错误现象：
- 插入
{ loc: { type: "Point", coordinates: [timestamp, 0] } }后，$geoWithin返回结果和实际时间重叠不一致 -
explain()显示executionStats.nReturned远大于预期，索引扫描量爆炸 - 聚合管道里混用
$geoIntersects和时间运算符（如$dateSubtract），触发隐式类型转换失败
真正适合时间重叠的索引策略：用 start 单字段索引 + 应用层剪枝
时间重叠本质是：存在某文档，满足 start ≤ queryEnd AND end ≥ queryStart。MongoDB 只能高效利用其中一端的索引，所以优先选高选择性的一端——通常是 start（因为查询常指定「我要找从 X 开始之后有重叠的」）。
实操建议：
- 建索引：
db.events.createIndex({ start: 1 })，别加end—— 复合索引在这里反而拖慢 - 查询时先用
start ≤ queryEnd快速缩小候选集，再在内存或聚合中用$expr补充end ≥ queryStart过滤 - 如果数据量大（百万级以上），加一个
status字段过滤无效区间（如status: "active"），避免索引包含大量历史归档数据
聚合阶段用 $expr 写重叠逻辑，但小心 $dateDiff 的时区陷阱
在 $match 里用 $expr 写时间重叠最灵活，比如：{ $expr: { $and: [ { $lte: ["$start", "$$queryEnd"] }, { $gte: ["$end", "$$queryStart"] } ] } }。但要注意日期字段的实际类型和时区。
容易踩的坑：
- 字段存的是字符串（
"2024-01-01T00:00:00Z"）而非Date类型 →$expr比较会按字典序错乱 - 前端传入的
queryStart是本地时间，没转 UTC 就塞进$$queryStart→ 和服务端存的 UTC 时间比，可能漏掉跨时区的重叠 - 用
$dateDiff计算重叠时长？它返回的是毫秒差，但若两区间不重叠，结果是负数——得额外用$max: [{ $dateDiff: ... }, 0]截断
复杂点在于：时间重叠本身是简单逻辑，但真实业务里往往要叠加状态过滤、权限校验、分页游标偏移——这些没法靠单个索引解决，得在应用层收口做二次筛选。别指望一条查询包打天下。
