有一个似乎可以优化mongodb查询的思路想跟大家讨论下,希望大家能指点一二
发布于 8 个月前 作者 wldlzt 3013 次浏览 来自 问答

如下,很普通的查询 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似乎没多少性能上的损耗),但重点想了解有没有实用化的意义?

7 回复

且不同查询业务针对同一个集合不同条件进行查询,难道要拼接出多个md5来?似乎也不太合理,但相信又能提升效率,这算是用空间换时间?

算空间换时间 这样优化的前提是你的查询条件涉及的field都是进行等值判断,并且你的条件是对查询field的顺序是有要求的。你得要求所有的开发都这样写并且按照统一的条件顺序。如果量特别大,查询次数多获取可以这样优化。 不过你可以试试加个缓存来应对查询

@ty4z2008 我这边有填过一些历史的坑,在不同mongodb版本的node驱动中做了一些解析器来统一旧新接口的不同,包括抹平一些废弃的函数,也就是说,在这个解析器里,即使人为调整查询字段的顺序,也可以被解析器按正常排序进行查询,也就不存在需要人为约定字段顺序。虽然目前自己的项目并不打算弄成md5来查询(非要做也不是不行,只是需要在业务架构上再进行调整),我只是对这个念头挺感兴趣的,如果官方来处理,是否在某种技术层面上也可以进行这样的优化呢?也就是在某种程度上数据在入库之后还有一个预热的自动md5化(不一定是md5)的过程(非现在的索引)…当然这只是我的一些想像

带来的效果很微小,要多很多额外的空间存储。 这样多个查询的条件应该结合业务进行重构。合并field

针对具体的场景可能会有价值。。。这种场景可能是:a,b, c , d , e …字段多,字段的顺序也有严格要求,且等值查询而非范围/模糊查询。数据量不大。 对于大部分的场景,这种可能并不实用,还不如搞一个组合索引有用。

@wldlzt 了解了一下文档索引,似乎跟我提的这个有点相近…算了,也明白只是心血来潮的一个想法,没太多价值

回到顶部