MongoDB索引和explain 分析
程序员文章站
2022-06-25 09:42:13
1. 索引管理创建索引并在后台运行db.COLLECTION_NAME.createIndex({"字段":排序方式}, {background: true});获取针对某个集合的索引db.COLLECTION_NAME.getIndexes()索引的大小db.COLLECTION_NAME.totalIndexSize()索引的重建db.COLLECTION_NAME.reIndex()索引的删除db.COLLECTION_NAME.dropIndex("INDEX-NAME"...
1. 索引管理
创建索引并在后台运行
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 对应的索引是删除不了的
2. explain 分析
测试可以使用js循环插入100万条数据 不使用索引字段 查询查看执行计划 ,然后给某个字段建立索引,使用索引字段作为查询条件 再查看执行计划进行分析
explain()也接收不同的参数,通过设置不同参数我们可以查看更详细的查询计划。
- queryPlanner:是默认参数,具体执行计划信息参考下面的表格。
- executionStats:会返回执行计划的一些统计信息(有些版本中和allPlansExecution等同)。
- allPlansExecution:用来获取所有执行计划,结果参数基本与上文相同。
2.1 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服务器信息 |
2.2 executionStats参数
参数 | 含义 |
---|---|
executionSuccess | 是否执行成功 |
nReturned | 返回的文档数 |
executionTimeMillis | 执行耗时 |
totalKeysExamined | 索引扫描次数 |
totalDocsExamined | 文档扫描次数 |
executionStages | 这个分类下描述执行的状态 |
stage | 扫描方式,具体可选值与上文的相同 |
nReturned | 查询结果数量 |
executionTimeMillisEstimate | 检索document获得数据的时间 |
inputStage.executionTimeMillisEstimate | 该查询扫描文档 index所用时间 |
works | 工作单元数,一个查询会分解成小的工作单元 |
advanced | 优先返回的结果数 |
docsExamined | 文档检查数目,与totalDocsExamined一致。检查了总共的document 个数,而从返回上面的nReturned数量 |
2.3 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,类型列举如下:
- 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)
3. 慢查询分析
- 开启内置的查询分析器,记录读写操作效率 db.setProfilingLevel(n,m),n的取值可选0,1,2
0表示不记录
1表示记录慢速操作,如果值为1,m必须赋值单位为ms,用于定义慢速查询时间的阈值
2表示记录所有的读写操作 - 查询监控结果 db.system.profile.find().sort({millis:-1}).limit(3)
- 分析慢速查询 应用程序设计不合理、不正确的数据模型、硬件配置问题,缺少索引等
- 解读explain结果 确定是否缺少索引
本文地址:https://blog.csdn.net/rzpy_qifengxiaoyue/article/details/108995230