我有一个很大的集合，数据由lat-lng坐标和时间与各自的索引排列（球形地理空间和下降的时间）。
现在每步时间大约有10,000个点，大约有2000个时间步长，我想找到5个点中的值，这些值在某个小时间段内最接近给定坐标。
问题在于，在记录数量达到1000万之后，地理空间查询的性能变得令人不安地变得不可预测：以前只需要大约3秒的时间来获取和处理，现在可以一直达到45，在我的情况下是不可接受的。
从我在mongodb文档中读到的内容来看，如果查询需要使用地理空间索引，默认情况下它优先于查询的任何其他部分，所以在我的情况下，搜索首先通过所有2000年的时间步骤，以找到所有10'000的最近点＆＃34;然后才将它缩小到我首先要求的50个步骤。这似乎更合理，因为即使.count（）沿着地理索引查询也需要花费相同的时间。
所以基本上，如果可能的话，我想以其他方式做到：首先缩小一些时间步骤，然后在这个相当小的数据集上执行$ near find或$ geoNear聚合。没有地理空间部分的查询也可以保持其性能。
在.find（）查询中提示另一个索引会破坏地理空间搜索，而$ geoNear在它之前不接受任何聚合管道步骤。由于某种原因在查询之前确保地理索引创建了第二个地理索引，因此聚合变得不可能
两步搜索或聚合本来是很好的，但似乎在mongo中没有这样的东西，虽然我认为它可以模仿将数据聚合到代理集合中，但这看起来是个糟糕的主意。
虽然我对mongodb索引工作和/或生命周期有一些渐渐的误解是可能的，因为请求时间并不总是那么糟糕，如果我刚写的内容可能是正确的。
以防万一：