从那里的教程中，我知道我可以根据请求在流星中对 MongoDB 集合进行排序，如下所示：
// Sorted by createdAt descending
Users.find({}, {sort: {createdAt: -1}})
但我觉得这个解决方案在性能方面并不是最优的。
因为如果我理解正确的话，每次有Users的请求，都会请求原始集合，然后一遍又一遍地排序。
那么一劳永逸地对整个集合进行排序，然后使用Users.find() 访问已经排序的集合不是更好吗？
问题是：我如何对整个集合进行永久排序，而不仅仅是找到的结果？
【问题讨论】：
这是 MiniMongo 的 known limitation，Meteor 的 MongoDB 功能（子集）的客户端实现。
“排序”一个 MongoDB 集合实际上并没有连贯的含义。它不会转化为一组具体的操作。你会按什么排序？是否有一种“自然”的方式来对一组结构可能不同的文档进行排序？
用于提高数据检索效率的机制是索引。在服务器上，如果可能，索引用于辅助排序：
在 MongoDB 中，排序操作可以通过根据索引中的排序检索文档来获得排序顺序。如果查询计划器无法从索引中获取排序顺序，它将在内存中对结果进行排序。使用索引的排序操作通常比不使用索引的排序操作具有更好的性能。此外，不使用索引的排序操作将在使用 32 MB 内存时中止。
由于集合没有固有的顺序，因此在 MongoDB 中保存有关顺序要求的信息的实体是游标。一个游标可以被多次抓取，理论上可以做成一个高效的有序数据抓取器。
不幸的是，目前情况并非如此。目前实现的方式，MiniMongo 没有索引，也没有按顺序缓存文档。每次获取光标时，它们都会重新排序。
排序是相当高效的（与排序一样高效，O(n*logn) 排序函数调用），但对于大型数据集，它可能会相当冗长并降低用户体验。
目前，如果您有一个特殊的用例需要重复访问以相同方式排序的大型数据集，您可以根据需要尝试通过观察游标来保留有序文档的缓存并在有变化时更新缓存。
【讨论】：