如下，很普通的查询 db.find({“a”: “1”,“b”: “2”,“c”: 3,“d”: 4,“e”: 5,“f”: 6}) 但如果，我把1、2、3、4、5、6的值拼接起来并md5化(假设变成{“md5”:“49ba59abbe56e057”})，保存在md5这个字段中，那理论上 db.find({“a”: “1”,“b”: “2”,“c”: 3,“d”: 4,“e”: 5,“f”: 6}) 即等同于 db.find({“md5”:“49ba59abbe56e057”}) 在两者都做索引的前提下，后者是否会提高查询效率？我大概知道后者有效率上的提升（拼接值再md5似乎没多少性能上的损耗），但重点想了解有没有实用化的意义？
算空间换时间 这样优化的前提是你的查询条件涉及的field都是进行等值判断，并且你的条件是对查询field的顺序是有要求的。你得要求所有的开发都这样写并且按照统一的条件顺序。如果量特别大，查询次数多获取可以这样优化。 不过你可以试试加个缓存来应对查询
@ty4z2008 我这边有填过一些历史的坑，在不同mongodb版本的node驱动中做了一些解析器来统一旧新接口的不同，包括抹平一些废弃的函数，也就是说，在这个解析器里，即使人为调整查询字段的顺序，也可以被解析器按正常排序进行查询，也就不存在需要人为约定字段顺序。虽然目前自己的项目并不打算弄成md5来查询（非要做也不是不行，只是需要在业务架构上再进行调整），我只是对这个念头挺感兴趣的，如果官方来处理，是否在某种技术层面上也可以进行这样的优化呢？也就是在某种程度上数据在入库之后还有一个预热的自动md5化（不一定是md5）的过程（非现在的索引）…当然这只是我的一些想像
针对具体的场景可能会有价值。。。这种场景可能是：a，b, c , d , e …字段多，字段的顺序也有严格要求，且等值查询而非范围/模糊查询。数据量不大。 对于大部分的场景，这种可能并不实用，还不如搞一个组合索引有用。
