什么是索引
索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构,它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单。索引的作用相当于图书的目录,可以根据目录中的页码快速找到所需的内容。索引目标是提高数据库的查询效率,没有索引的话,查询会进行全表扫描(scan every document in a collection),数据量大时严重降低了查询效率。默认情况下Mongo在一个集合(collection)创建时,自动地对集合的_id创建了唯一索引。
索引类型
单键索引
MongoDB支持所有数据类型中的单个字段索引,并且可以在文档的任何字段上定义。对于单个字段索引,索引键的排序顺序无关紧要,因为MongoDB可以在任一方向读取索引。
单键索引的创建方式如下:
// 排序方式:1为升序,-1为降序
db.集合名.createIndex({"字段名":排序方式})
TTL索引是MongoDB中一种特殊的索引, 可以支持文档在一定时间之后自动过期删除。目前TTL索引只能在单字段上建立,并且字段类型必须是日期类型。
db.集合名.createIndex({"日期字段":排序方式}, {expireAfterSeconds: 秒数})
复合索引
通常我们需要在多个字段的基础上搜索表/集合,这是非常频繁的。 如果是这种情况,我们可能会考虑在MongoDB中制作复合索引。 复合索引支持基于多个字段的索引,这扩展了索引的概念并将它们扩展到索引中的更大域。
制作复合索引时要注意的重要事项包括:字段顺序与索引方向。示例如下:
db.集合名.createIndex( { "字段名1" : 排序方式, "字段名2" : 排序方式 } )
多键索引
针对属性包含数组数据的情况,MongoDB支持针对数组中每一个element创建索引,Multikey indexes支持strings,numbers和nested documents。创建方式同单键索引,也就是说--只要在类型为数组的键上创建的索引均为多键索引。
地理空间索引
针对地理空间坐标数据创建索引。
- 2dsphere索引,用于存储和查找球面上的点
- 2d索引,用于存储和查找平面上的点
示例如下:
db.company.insert(
{
loc : { type: "Point", coordinates: [ 116.482451, 39.914176 ] },
name: "大望路地铁",
category : "Parks"
}
)
// 注意:参数不是1或-1,为2dsphere 或者 2d。还可以建立组合索引
db.company.createIndex( { loc : "2dsphere" } )
db.company.find({
"loc" : {
"$geoWithin" : {
"$center":[[116.482451,39.914176],0.05]
}
}
})
全文索引
MongoDB提供了针对string内容的文本查询,Text Index支持任意属性值为string或string数组元素的索引查询。注意:一个集合仅支持最多一个Text Index,中文分词不理想,推荐ES。
示例如下:
db.集合.createIndex({"字段": "text"})
db.集合.find({"$text": {"$search": "coffee"}})
哈希索引
针对属性的哈希值进行索引查询,当要使用Hashed index时,MongoDB能够自动的计算hash值,无需程序计算hash值。注:hash index仅支持等于查询,不支持范围查询。
示例如下:
db.集合.createIndex({"字段": "hashed"})
索引和explain分析
索引管理
创建索引并在后台运行
db.COLLECTION_NAME.createIndex({"字段":排序方式}, {background: true})
获取针对某个集合的索引
db.COLLECTION_NAME.getIndexes()
索引的大小
db.COLLECTION_NAME.totalIndexSize()
索引的重建
db.COLLECTION_NAME.reIndex()
索引的删除
db.COLLECTION_NAME.dropIndex("INDEX-NAME")
db.COLLECTION_NAME.dropIndexes()
注意: _id 对应的索引是删除不了的
explain分析
db.rubin_collection.find({}).explain()
explain()也接收不同的参数,通过设置不同参数我们可以查看更详细的查询计划。
- queryPlanner:queryPlanner是默认参数,具体执行计划信息参考下面的表格
- executionStats:executionStats会返回执行计划的一些统计信息(有些版本中和allPlansExecution等同)
- allPlansExecution:allPlansExecution用来获取所有执行计划,结果参数基本与上文相同
queryPlanner 默认参数
参数 | 含义 |
plannerVersion | 查询计划版本 |
namespace | 要查询的集合(该值返回的是该query所查询的表)数据库.集合 |
indexFilterSet | 针对该query是否有indexFilter |
parsedQuery | 查询条件 |
winningPlan | 被选中的执行计划 |
winningPlan.stage | 被选中执行计划的stage(查询方式),常见的有:COLLSCAN/全表扫描:(应该知道就是CollectionScan,就是所谓的“集合扫描”,和mysql中table scan/heap scan类似,这个就是所谓的性能最烂最无奈的由来)、IXSCAN/索引扫描:(是IndexScan,这就说明我们已经命中索引了)、FETCH/根据索引去检索文档、SHARD_MERGE/合并分片结果、IDHACK/针对_id进行查询等 |
winningPlan.inputStage | 用来描述子stage,并且为其父stage提供文档和索引关键字 |
winningPlan.stage的child stage | 如果此处是IXSCAN,表示进行的是index scanning |
winningPlan.keyPattern | 所扫描的index内容 |
winningPlan.indexName | winning plan所选用的index |
winningPlan.isMultiKey | 是否是Multikey,此处返回是false,如果索引建立在array上,此处将是true |
winningPlan.direction | 此query的查询顺序,此处是forward,如果用了.sort({字段:-1}),将显示backward |
filter | 过滤条件 |
winningPlan.indexBounds | winningplan所扫描的索引范围,如果没有制定范围就是[MaxKey,MinKey],这主要是直接定位到mongodb的chunck中去查找数据,加快数据读取 |
rejectedPlans | 被拒绝的执行计划的详细返回,其中具体信息与winningPlan的返回中意义相同,故不在此赘述) |
serverInfo | MongoDB服务器信息 |
executionStats参数
参数 | 含义 |
executionSuccess | 是否执行成功 |
nReturned | 返回的文档数 |
executionTimeMillis | 执行耗时 |
totalKeysExamined | 索引扫描次数 |
totalDocsExamined | 文档扫描次数 |
executionStages | 这个分类下描述执行的状态 |
stage | 扫描方式,具体可选值与上文的相同 |
nReturned | 查询结果数量 |
executionTimeMillisEstimate | 检索document获得数据的时间 |
inputStage.executionTimeMillisEstimate | 该查询扫描文档 index所用时间 |
works | 工作单元数,一个查询会分解成小的工作单元 |
advanced | 优先返回的结果数 |
docsExamined | 文档检查数目,与totalDocsExamined一致。检查了总共的document个数,而从返回上面的nReturned数量 |
executionStats返回逐层分析
第一层,executionTimeMillis最为直观explain返回值是executionTimeMillis值,指的是这条语句的执行时间,这个值当然是希望越少越好。
其中有3个executionTimeMillis,分别是:
- executionStats.executionTimeMillis 该query的整体查询时间
- executionStats.executionStages.executionTimeMillisEstimate 该查询检索document获得数据的时间
- executionStats.executionStages.inputStage.executionTimeMillisEstimate 该查询扫描文档 index 所用时间
第二层,index与document扫描数与查询返回条目数 这个主要讨论3个返回项 nReturned、totalKeysExamined、totalDocsExamined,分别代表该条查询返回的条目、索引扫描条目、文档扫描条目。 这些都是直观地影响到executionTimeMillis,我们需要扫描的越少速度越快。 对于一个查询,我们最理想的状态是:nReturned=totalKeysExamined=totalDocsExamined。
第三层,stage状态分析。那么又是什么影响到了totalKeysExamined和totalDocsExamined?是stage的类型。
类型列举如下:
- COLLSCAN:全表扫描
- IXSCAN:索引扫描
- FETCH:根据索引去检索指定document
- SHARD_MERGE:将各个分片返回数据进行merge
- SORT:表明在内存中进行了排序
- LIMIT:使用limit限制返回数
- SKIP:使用skip进行跳过
- IDHACK:针对_id进行查询
- SHARDING_FILTER:通过mongos对分片数据进行查询
- COUNT:利用db.coll.explain().count()之类进行count运算
- TEXT:使用全文索引进行查询时候的stage返回
- PROJECTION:限定返回字段时候stage的返回
对于普通查询,我希望看到stage的组合(查询的时候尽可能用上索引):
- Fetch+IDHACK
- Fetch+IXSCAN
- Limit+(Fetch+IXSCAN)
- PROJECTION+IXSCAN
- SHARDING_FITER+IXSCAN
不希望看到包含如下的stage:
- COLLSCAN:全表扫描
- SORT:使用sort但是无index
- COUNT:不使用index进行count
慢查询分析
开启内置的查询分析器,记录读写操作效率:
db.setProfilingLevel(n,m)
其中:n的取值可选0,1,2
- 0表示不记录
- 1表示记录慢速操作。如果值为1,m必须赋值单位为ms,用于定义慢速查询时间的阈值
- 2表示记录所有的读写操作
查询监控结果:
db.system.profile.find().sort({millis:-1}).limit(3)
查询出慢日志之后,我们可以根据上文的内容,适当的添加索引去提高查询效率。
MongoDB索引底层实现原理分析
MongoDB 是文档型的数据库,它使用BSON格式保存数据,比关系型数据库存储更方便。比如之前关系型数据库中处理用户、订单等数据要建立对应的表,还要建立它们之间的关联关系。但是BSON就不一样了,我们可以把一条数据和这条数据对应的数据都存入一个BSON对象中,这种形式更简单,通俗易懂。MySQL是关系型数据库,数据的关联性是非常强的,区间访问是常见的一种情况,底层索引组织数据使用B+树,B+树由于数据全部存储在叶子节点,并且通过指针串在一起,这样就很容易的进行区间遍历甚至全部遍历。MongoDB使用B-树,所有节点都有Data域,只要找到指定索引就可以进行访问,单次查询从结构上来看要快于MySQL。3
B-树是一种自平衡的搜索树,形式很简单:
B-树的特点:
- 多路 非二叉树
- 每个节点 既保存数据 又保存索引
- 搜索时 相当于二分查找
B+树是B-树的变种:
B+ 树的特点:
- 多路非二叉
- 只有叶子节点保存数据
- 搜索时 也相当于二分查找
- 增加了 相邻节点指针
从上面我们可以看出最核心的区别主要有俩,一个是数据的保存位置,一个是相邻节点的指向。就是这俩造成了MongoDB和MySQL的差别。
- B+树相邻接点的指针可以大大增加区间访问性,可使用在范围查询等,而B-树每个节点 key 和 data 在一起 适合随机读写 ,而区间查找效率很差
- B+树更适合外部存储,也就是磁盘存储,使用B-结构的话,每次磁盘预读中的很多数据是用不上的数据。因此,它没能利用好磁盘预读的提供的数据。由于节点内无 data 域,每个节点能索引的范围更大更精确
- 注意这个区别相当重要,是基于(1)(2)的,B-树每个节点即保存数据又保存索引,树的深度小,所以磁盘IO的次数很少。B+树只有叶子节点保存,较B树而言深度大磁盘IO多,但是区间访问比较好
以上就是本文的全部内容了。欢迎小伙伴们积极留言交流~~~
文章评论