MongoDB查时间区间慢的根本原因是时间字段类型错误或索引策略不当；须确保字段为Date类型，并建立{startAt:1,endAt:1}复合索引，避免$expr计算、时区混乱及运行时日期解析。
用 $gte 和 $lte 查时间区间，但查得慢？
MongoDB 里查“某天所有日程”或“下周会议”，直接套 $gte/$lte 很容易慢——尤其集合大、时间字段没建对索引。根本原因不是语法错，是时间字段类型和索引策略不匹配。
- 确保时间字段是
Date类型（不是字符串），否则$gte只能全表扫 - 复合索引必须把时间字段放最左：比如查
startAt到endAt之间的日程，建索引优先考虑{ startAt: 1, endAt: 1 }，而不是反过来 - 避免在查询里对时间字段做计算，例如
{ $expr: { $gt: [{ $dayOfMonth: "$startAt" }, 15] } }会跳过索引
日程重叠查询怎么写才不漏、不慢？
典型需求：“查今天与用户A日程有时间重叠的所有日程”。这不是简单查单个时间点，而是判断两个区间是否相交，标准逻辑是：queryStart = eventStart。
- MongoDB 写法是：
{ startAt: { $lte: queryEnd }, endAt: { $gte: queryStart } } - 这个查询必须依赖
{ startAt: 1, endAt: 1 }索引才能高效；只建{ startAt: 1 }的话，$gte在endAt上无法走索引 - 如果日程极短（如会议仅15分钟），而查询跨度大（如查整月），考虑加一个
dateDay字段（存YYYY-MM-DD字符串）并建索引，先缩小范围再精筛
日历视图按月/周聚合，别用 $group 硬扛
前端要渲染一个月的格子，每个格子显示当天日程数或摘要，直接用 $group + $dateToString 做聚合，在万级日程下响应常超2s。
- 更稳的做法是：应用层按天发多个轻量查询，例如循环查 30 天的
{ startAt: { $lte: dayEnd }, endAt: { $gte: dayStart } }，每条走索引，总耗时反而更低 - 如果必须聚合，把日期归一化提前算好：插入日程时就存
yearMonth: "2024-06"、weekOfYear: 24等字段，查当月就直接{ yearMonth: "2024-06" }，不用运行时解析 -
$dateToString在聚合管道里无法利用索引，纯属 CPU 消耗，能预计算就别留到查询时
时区处理不统一，查出来的时间全是错的
用户在北京、日程存在 UTC 时间、前端又按本地时区渲染——三个环节时区不一致，startAt 查出来的值看着对，实际展示偏了8小时。
- MongoDB 本身不存时区，
Date类型本质是 UTC 毫秒数；所有写入前必须转成 UTC，不要存带 offset 的字符串 - 应用层读取后，由业务代码（不是 DB）负责转成本地时区展示；例如 Node.js 用
date.toLocaleString("zh-CN", { timeZone: userTZ }) - 千万别在查询里用
$add加减小时数来“修正”时区，这会让索引失效，且跨夏令时会出错
时间模型真正难的不是写对一条查询，而是从字段设计、索引选择、时区流转到前端渲染，每个环节都得对齐 UTC 这一根线。漏掉任意一环，性能或正确性就会突然崩掉。
