问题根源：为什么 MongoDB 日期范围查询会不准确？
日期字段的实际存储类型及不一致带来的影响
在 MongoDB 中，日期可以以多种形式存储：ISODate/Date、字符串、甚至数字时间戳。类型不一致会导致同一字段参与比较时表现不同，进而影响日期范围查询的准确性。
举例：若某条记录的 orderDate 为字符串 "2024-01-01" 而另一条为 ISODate("2024-01-01"), 使用 $gte/ $lt 进行范围查询时，字符串的字典序比较可能产生错误的边界，例如 "2024-10-01" 可能排在 "2024-02-01" 之前，从而导致漏检或多检。
此外，不同字段的格式混用也会让同一查询在多条记录上得到不一致的结果，尤其是在没有统一的字段注释或数据字典时。
时区与边界处理不当
MongoDB 的日期类型以 UTC 存储。因此，如果在应用端未将时间统一到 UTC，就会在边界查询时出现偏差，导致范围边界不稳定。
例如，在构建一个月度查询时，若将本地时区时间直接传给查询参数，时区偏移会改变边界值，使得原本在边界点的文档被错误地包含或排除。
查询环境中的混淆：是否把日期字段作为字符串进行比较
如果查询条件中的日期也是以字符串形式出现，同样会出现边界不一致的问题；因此，查询侧和存储侧必须使用同一数据类型，否则就算边界条件正确，结果也会错乱。
在没有显式类型断言的情况下，数据库会按照字段类型进行比较，这意味着不同类型的比较成本和结果可能完全不同。
确保数据类型一致性来解决
规范化存储：统一为 ISODate
将字段统一成 MongoDB 的日期类型（ISODate/Date），可以避免类型混淆导致的范围查询错误。
在数据迁移阶段，先建立备份，再执行类型转换；迁移后，所有历史数据应转为日期类型，包括字符串时间戳。
转换后，使用时间边界进行查询时，结果可预测且一致，边界不会因为类型不同而改变。
// 使用 aggregation + $toDate 将字符串日期字段转换为日期类型的示例（pipeline 更新）
db.orders.updateMany({ orderDate: { $type: "string" } },[{ $set: { orderDate: { $toDate: "$orderDate" } } }]
)
应用层面的一致性：在查询前构建正确的 Date 对象
在应用层将用户输入的日期字符串解析为 Date 对象，再传递给 MongoDB 查询，能够确保查询参数的类型一致。
示例中，使用 ISODate/XDate 形式，并在查询时按 UTC 边界进行区间过滤。
// Node.js 端示例：将用户输入的日期字符串解析为 Date 对象
const start = new Date("2024-01-01T00:00:00Z"); // UTC
const end = new Date("2024-02-01T00:00:00Z");db.orders.find({ orderDate: { $gte: start, $lt: end }});
迁移与回滚的实践
在迁移过程中，记录每一步变更，并在回滚策略中保留原始数据。对于大数据集，建议分批处理以控制阻塞时间和风险。
将转换后的数据与索引进行对齐，确保 索引仍然高效，避免因数据类型变更导致查询计划改变。
// 创建索引示例（确保对 date 字段有栈式索引，提升范围查询性能）
db.orders.createIndex({ orderDate: 1 })
诊断与验证：如何确认数据类型统一生效
检查现有数据的类型分布
通过聚合管道统计不同类型的记录数量，发现潜在的类型不一致，有助于定位需要转换的记录。
示例查询：$type 运算符用于筛选非日期类型的文档。
db.orders.aggregate([{ $group: { _id: { t: { $type: "$orderDate" } }, count: { $sum: 1 } } }
])
对比查询前后结果的一致性
在执行转换前后，执行相同的日期范围查询，比较返回的文档数量是否稳定。若觉察差异，应进一步检查边界值。
一致性高的指示是：同一边界条件在不同时间执行，返回集“几乎不变”且没有错漏。
常见监控指标
监控查询执行计划的成本、索引使用情况，以及 返回文档的时间分布，以判定日期字段是否被正确地比较。
# 使用 MongoDB 的 explain 查看查询计划
db.orders.find({ orderDate: { $gte: new Date("2024-01-01"), $lt: new Date("2024-02-01") } }).explain("executionStats")
