MongoDB通配符索引的用法实例
|
db.collection.createIndex( 注意：通配符索引不支持在使用wildcardProjection的时候混合使用包含和排除语句，除了明确指定包含_id字段的时候。 在全字段的基础上创建一个明确不包含哪些字段的索引： db.collection.createIndex( 3、通配符索引的行为 通配符索引的行为根据其字段类型不同而有所不同。 字段为对象 如果是对象的话，会将对象中的内容存储到索引中，通配符索引会把对象中的所有嵌套对象加载到索引中。 字段为数组 如果是数组的话，通配符索引遍历数组并且将每个元素都存储到索引中。 如果数组中的元素是一个对象的话，通配符索引把对象中的内容加载到索引中，像上面的加载对象一样。 如果数组中的元素是一个数组的话(就是多维数组)，通配符索引并不迭代嵌套数组，相反是把整个嵌套数组作为一个值来看。 其他类型 把值记录到数组中。 通配符索引会持续迭代任何的嵌套对象或者数组直到最底层(就是不能在迭代为止)，然后它会索引全路径。 通配符索引对于显示数组位置的查询 通配符索引虽然不会记录给定数组中的元素下标，但是，MongoDB仍然可以选择通配符索引来满足包含一个或多个显式数组索引的字段路径的查询(for example, parentArray.0.nestedArray.0) 由于为每个连续嵌套数组定义索引边界的复杂性日益增加，如果该路径包含8个以上的显式数组索引，MongoDB不会考虑使用通配符索引来回答查询中的给定字段路径。MongoDB仍然可以考虑使用通配符索引来回答查询中的其他字段路径。 如果超过了8个以上显示数组索引的话MongoDB 会考虑另外的索引或者执行全集合扫描。如下结构： { 请注意，通配符索引本身对索引文档时遍历文档的深度没有任何限制；该限制仅适用于显式指定精确数组索引的查询。通过发出没有显式数组索引的相同查询，MongoDB可以选择通配符索引来回答查询。 4、通配符索引的限制 1.首先通配符索引是一个稀疏索引，只存放存在的字段在索引里面，不存在的不存放，也就是说当你使用{$exists:false}的时候，是不会走索引的，是全集合扫描。 db.test_new_wildidx.find({“block.attr”:{$exists:false}}) db.test_new_wildidx.find({“block.attr”:{$exists:true}}) 但是支持true的。 2.通配符索引不支持直接等于/不等于一个对象或者数组。 通配符索引会将对象或者数组中的元素加载到索引中，而不是整体放到索引中。故通配符索引不支持直接用文档或者数组来匹配。 所以上面的例子如果 7777:PRIMARY> db.test_new_wildidx.find({“block.attr.address_new”: [“haicheng”, “beijing”, “chongqing”]}) 就是想匹配整个数组的话，是不可能用到通配符索引的。 那么如果有这个需求该如何解决？Db.test_new_wildidx.createIndex({“block.attr.address_new”:1}) 通过这个索引来解决。 虽然通配符索引不支持整个文档或者对象直接精准匹配查询，但是支持数组或者对象为空{} 这种操作: 7777:PRIMARY> db.test_new_wildidx.find({“block.attr”: {}}) 3. 通配符索引支持如下索引类型或者或者属性： Compound TTL Text 2d (Geospatial) 2dsphere (Geospatial) Hashed Unique 4.通配符索引不支持文档中的数组$ne null这种。其实不光是数组，别的字段也同样，只要是$ne都不会使用通配符索引。 5、总结 通配符索引在一定程度上可以应对在建模初期对于索引建立疏忽的遗漏，但是如果一味依赖通配符索引来解决查询中的各种精确字段的匹配那就是郑人买履了，在实际测试中通配符索引和精确字段的索引相比随着数据的增长效率逐渐下滑。这也是官方不是很建议使用通配符索引来替代常规索引的原因。 本文来自脚本之家，原文链接：https://www.jb51.net/article/195111.htm
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
本文素材来自互联网 （编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
