在mongo中也提供了一个explain()方法，该方法能够提供大量与查询相关的信息。对于速度比较慢的查询来说，它是最重要的性能分析工具之一。通过查看一个查询的explain()输出信息，可以知道查询使用了哪个索引，以及是如何使用的。对于任意查询，都可以在最后添加一个explain()调用（与调用sort()或者limit()一样，不过explain()必须放在最后）。
最常见的explain()输出有两种类型：使用索引的查询和没有使用索引的查询。其输出的信息可能如图1：
返回信息详细介绍：
“millis”表明了这个查询的执行时间。数字越小，则说明这个查询的效率越高。
“n”则表明了实际返回的文档数量。
“nscanned“描述了MongoDB在执行这个查询时搜索了多少文档。
”cursor“本查询返回值为”BasicCursor“则说明该查询未使用索引，所以才会搜索了所有的文档。如返回”BtreeCursor“则表示查询中使用了索引。
”isMultiKey“用于说明是否使用了多键索引。
”nYield“指本次查询暂停的次数。在查询期间，如果有与入请求需要处理，为了让写入请求能够顺利执行，查询会周期性的释放它的锁。
数据库性能对软件整体性能的影响是不言而喻的，那么，当我们使用MongoDB时改如何提高数据库性能呢？1.范式化与反范式化
在项目设计阶段，明确集合的用途是对性能调优非常重要的一步。
从性能优化的角度来看，集合的设计我们需要考虑的是集合中数据的常用 *** 作，例如我们需要设计一个日志（log）集合，日志的查看频率不高，但写入频率却很高，那么我们就可以得到这个集合中常用的 *** 作是更新（增删改）。如果我们要保存的是城市列表呢？显而易见，这个集合是一个查看频率很高，但写入频率很低的集合，那么常用的 *** 作就是查询。
对于频繁更新和频繁查询的集合，我们最需要关注的重点是他们的范式化程度，在上篇范式化与反范式化的介绍中我们了解到，范式化与反范式化的合理运用对于性能的提高至关重要。然而这种设计的使用非常灵活，假设现在我们需要存储一篇图书及其作者，在MongoDB中的关联就可以体现为以下几种形式：
1.完全分离（范式化设计）
示例1：
View Code
{
"_id" : ObjectId("5124b5d86041c7dca81917"),
"title" : "如何使用MongoDB",
"author" : [
ObjectId("144b5d83041c7dca84416"),
ObjectId("144b5d83041c7dca84418"),
ObjectId("144b5d83041c7dca84420"),
]
}
我们将作者(comment) 的id数组作为一个字段添加到了图书中去。这样的设计方式是在非关系型数据库中常用的，也就是我们所说的范式化设计。在MongoDB中我们将与主键没有直接关系的图书单独提取到另一个集合，用存储主键的方式进行关联查询。当我们要查询文章和评论时需要先查询到所需的文章，再从文章中获取评论id，最后用获得的完整的文章及其评论。在这种情况下查询性能显然是不理想的。但当某位作者的信息需要修改时，范式化的维护优势就凸显出来了，我们无需考虑此作者关联的图书，直接进行修改此作者的字段即可。
2.完全内嵌（反范式化设计）
示例2：
View Code
{
"_id" : ObjectId("5124b5d86041c7dca81917"),
"title" : "如何使用MongoDB",
"author" : [
{
"name" : "丁磊"
"age" : 40,
"nationality" : "china",
},
{
"name" : "马云"
"age" : 49,
"nationality" : "china",
},
{
"name" : "张召忠"
"age" : 59,
"nationality" : "china",
},
]
}
在这个示例中我们将作者的字段完全嵌入到了图书中去，在查询的时候直接查询图书即可获得所对应作者的全部信息，但因一个作者可能有多本著作，当修改某位作者的信息时时，我们需要遍历所有图书以找到该作者，将其修改。
3.部分内嵌（折中方案）
示例3：
View Code
{
"_id" : ObjectId("5124b5d86041c7dca81917"),
"title" : "如何使用MongoDB",
"author" : [
{
"_id" : ObjectId("144b5d83041c7dca84416"),
"name" : "丁磊"
},
{
"_id" : ObjectId("144b5d83041c7dca84418"),
"name" : "马云"
},
{
"_id" : ObjectId("144b5d83041c7dca84420"),
"name" : "张召忠"
},
]
}
这次我们将作者字段中的最常用的一部分提取出来。当我们只需要获得图书和作者名时，无需再次进入作者集合进行查询，仅在图书集合查询即可获得。
这种方式是一种相对折中的方式，既保证了查询效率，也保证的更新效率。但这样的方式显然要比前两种较难以掌握，难点在于需要与实际业务进行结合来寻找合适的提取字段。如同示例3所述，名字显然不是一个经常修改的字段，这样的字段如果提取出来是没问题的，但如果提取出来的字段是一个经常修改的字段（比如age）的话，我们依旧在更新这个字段时需要大范围的寻找并依此进行更新。
在上面三个示例中，第一个示例的更新效率是最高的，但查询效率是最低的，而第二个示例的查询效率最高，但更新效率最低。所以在实际的工作中我们需要根据自己实际的需要来设计表中的字段，以获得最高的效率。
本文干货较多，建议收藏学习。先将文章结构速览奉上：
一、背景
二、MongoDB执行计划
2.1 queryPlanner信息
2.2 executionStats信息
2.3 allPlansExecution信息
三、云上用户建索引常见问题及优化方法
3.1 等值类查询常见问题及优化方法
3.1.1 同一类查询创建多个索引问题
3.1.2 多字段等值查询组合索引顺序非最优
3.1.3 最左原则包含关系引起的重复索引
3.1.4 唯一字段和其他字段组合引起的无用重复索引
3.2 非等值类查询常见问题及优化方法
3.2.1 非等值组合查询索引不合理创建
3.2.2 等值+非等值组合查询索引字段顺序不合理
3.2.3 不同类型非等值查询优先级问题
3.3 OR类查询常见问题及优化方法
3.3.1 普通OR类查询优化方法
3.3.2 复杂OR类查询优化方法
3.4 SORT类排序查询常见问题及优化方法
3.4.1 单字段正反序排序查询引起的重复索引
3.4.2 多字段排序查询正反序问题引起索引无效
3.4.3 等值查询+多字段排序组合查询
3.4.4 等值查询+非等值查询+SORT排序查询
3.4.5 OR+SORT组合排序查询
3.5 无用索引优化方法
四、MongoDB不同类型查询最优索引总结
腾讯云MongoDB当前已服务于 游戏 、电商、社交、教育、新闻资讯、金融、物联网、软件服务、 汽车 出行、音视频等多个行业。
腾讯MongoDB团队在配合用户分析问题过程中，发现 云上用户存在如下索引共性问题 ，主要集中在如下方面：
本文 重点分析总结腾讯云上用户索引创建不合理相关的问题 ，通过本文可以学习到MongoDB的以下知识点：
本文总结的 《最优索引规则创建大全》 不仅仅适用于MongoDB，很多规则 同样适用于MySQL等关系型数据库 。
判断索引选择及不同索引执行家伙信息可以通过explain *** 作获取， MongoDB通过explain来获取SQL执行过程信息 ，当前持续explain的请求命令包含以下几种：
aggregate, count, distinct, find, findAndModify, delete, mapReduce, and update。
详见explain官网链接：
https://docs.MongoDB.com/manual/reference/command/explain/
explain可以携带以下几个参数信息，各参数信息功能如下：
2.1 queryPlanner信息
获取MongoDB查询优化器选择的最优索引和拒绝掉的非最优索引，并给出各个候选索引的执行阶段信息，queryPlanner输出信息如下：
queryPlanner输出主要包括如下信息：
parsedQuery信息
内核对查询条件进行序列化，生成一棵expression tree信息，便于候选索引查询匹配。
winningPlan信息
rejectedPlans信息
输出信息和winningPlan类似，记录这些拒绝掉索引的执行stage信息。
2.2 executionStats信息
explain的executionStats参数除了提供上面的queryPlanner信息外，还提供了最优索引的执行过程信息，如下：
上面是通过executionStats获取执行过程的详细信息，其中字段信息较多，平时分析索引问题最常用的几个字段如下：
executionStats输出字段较多，其他字段将在后续《MongoDB内核index索引模块实现原理》中进行进一步说明。
在实际分析索引问题是否最优的时候，主要查看以下三个统计项：
executionStats.totalKeysExamined
executionStats.totalDocsExamined
executionStats .nReturned
如果存在以下情况则说明索引存在问题，可能索引不是最优的：
1. executionStats.totalKeysExamine远大于executionStats .nReturned
2. executionStats. totalDocsExamined远大于executionStats .nReturned
2.3 allPlansExecution信息
allPlansExecution参数对应输出信息和executionStats输出信息类似，只是多了所有候选索引(包括reject拒绝的非最优索引)的执行过程，这里不再详述。
2.4 总结
从上面的几个explain执行计划参数输出信息可以看出，各个参数的功能各不相同，总结如下：
queryPlanner
输出索引的候选索引，包括最优索引及其执行stage过程(winningPlan)+其他非最优候选索引及其执行stage过程。
注意： queryPlanner没有真正在表中执行整个SQL，只做了查询优化器获取候选索引过程，因此可以很快返回。
executionStats
相比queryPlanner参数，executionStats会记录查询优化器根据所选最优索引执行SQL的整个过程信息，会真正执行整个SQL。
allPlansExecution
和executionStats类似，只是多了所有候选索引的执行过程。
在和用户一起优化腾讯云上MongoDB集群索引过程中，以及和头部用户的交流中发现很多用户对如何创建最优索引有较为严重的错误认识，并且很多是绝大部分用户的共性问题，因此在本文中将这些问题汇总如下：
3.1 等值类查询常见问题及优化方法
如下三个查询：
用户创建了如下3个索引：
{a:1, b:1, c:1}
{b:1, a:1, c:1}
{c:1, a:1, b:1}
实际上这3个查询属于同一类查询，只是查询字段顺序不一样，因此只需创建任一个索引即可满足要求。验证过程如下：
从上面的expalin输出可以看出，3个查询都走向了同一个索引。
例如test表有多条数据，每条数据有3个字段，分别为a、b、c。其中a字段有10种取值，b字段有100种取值，c字段有1000种取值，称为各个字段值的 “区分度” 。
用户查询条件为db.test.find({"a":"xxx", "b":"xxx", "c":"xxx"})，创建的索引为{a:1, b:1, c:1}。如果只是针对这个查询，该查询可以创建a，b，c三字段的任意组合，并且其SQL执行代价一样，通过hint强制走不通索引，验证过程如下：
从上面的执行计划可以看出，多字段等值查询各个字段的组合顺序对应执行计划代价一样。绝大部分用户在创建索引的时候，都是直接按照查询字段索引组合对应字段。
但是，单就这一个查询，这里有个不成文的建议，把区分度更高的字段放在组合索引左边，区分度低的字段放到右边。这样做有个好处，数据库组合索引遵从最左原则，就是当其他查询里面带有区分度最高的字段时，就可以快速排除掉更多不满足条件的数据。
例如用户有如下两个查询：
用户创建了如下两个索引：
{b:1, c:1}
{a:1,b:1,c:1}
这两个查询中，查询2中包含有查询1中的字段，因此可以用一个索引来满足这两个查询要求，按照最左原则，查询1字段放左边即可，该索引可以优化为：b,c字段索引+a字段索引，b,c字段顺序可以根据区分排序，加上c字段区分度比b高，则这两个查询可以合并为一个{c:1, b:1, a:1}。两个查询可以走同一个索引验证过程如下：
从上面输出可以看出，这两个查询都走了同一个索引。
例如用户有以下两个查询：
用户为这两个查询创建了两个索引，{a:1, b:1}和{a:1, c:1}，但是a字段取值是唯一的，因此这两个查询中a以外的字段无用，一个{a:1}索引即可满足要求。
3.2 非 等值类查询常见索引错误创建方法及如何创建最优索引
假设用户有如下查询：
a,c两个字段都是非等值查询，很多用户直接添加了{a:1, c:1}索引，实际上多个字段的非等值查询，只有最左边的字段才能走索引，例如这里只会走a字段索引，验证过程如下：
从上面执行计划可以看出，索引数据扫描了10行(也就是a字段满足a:{$gte:1}条件的数据多少)，但是实际上只返回了4条满足{a:{$gte:1}, c:{$lte:1}}条件的数据，可以看出c字段无法做索引。
同理，当查询中包含多个字段的范围查询的适合，除了最左边第一个字段可以走索引，其他字段都无法走索引。因此，上面例子中的查询候选索引为{a:1}或者{b:1}中任何一个就可以了，组合索引中字段太多会占用更多存储成本、同时占用更多IO资源引起写放大。
例如下面查询：
如上查询，d字段为非等值查询，e字段为等值查询，很多用户遇到该类查询直接创建了{d:1, e:1}索引，由于d字段为非等值查询，因此e字段无法走索引，验证过程如下：
从上面验证过程可以看出，等值类和非等值类组合查询对应组合索引，最优索引应该优先把等值查询放到左边，上面查询对应最优索引{e:1, d:1}
前面用到的非等值查询 *** 作符只提到了比较类 *** 作符，实际上非等值查询还有其他 *** 作符。常用非等值查询包括：$gt、$gte、$lt、$lte、$in、$nin、$ne、$exists、$type等，这些非等值查询在绝大部分情况下存在如下优先级：
从上到下优先级更高，例如下面的查询：
如上，该查询等值部分查询最优索引{a:1, b:1}(假设a区分度比b高)；非等值部分，因为$in *** 作符优先级最高，排他性更好，加上多个字段非等值查询只会有一个字段走索引，因此非等值部分最优索引为{g:1}。
最终该查询最优索引为：”等值部分最优索引”与”非等值部分最优索引”拼接，也就是{a:1,b:1, g:1}
3.3 OR类查询常见索引错误创建方法及如何创建最优索引
例如下面的OR查询：
该查询很多用户直接创建了{b:1, d:1, c:1, a:1}，用户创建该索引后，发现用户还是全表扫描。
OR类查询需要给数组中每个查询添加索引，例如上面or数组中实际包含{ b: 0, d:0 }和 {"c":1, "a":{$gte:4}}查询，需要创建两个查询的最优索引，也就是{b:1, d:1}和{c:1, a:1}，执行计划验证过程如下(该测试表总共10条数据)：
从上面执行计划可以看出，如果该OR类查询走{b:1, d:1, c:1, a:1}索引，则实际上做了全表扫描。如果同时创建{b:1, d:1}、{c:1, a:1}索引，则直接走两个索引，其执行key和doc扫描行数远远小于全表扫描。
这里在提升一下OR查询难度，例如下面的查询：
上面的查询可以转换为如下两个查询：
如上图，查询1拆分后的两个查询2和查询3组成or关系，因此对应最优索引需要创建两个，分表是：{f:1, g:1, b:1, d:1} 和 {f:1, g:1, b:1, d:1}。对应执行计划如下：
同理，不管怎么增加难度，OR查询最终可转换为多个等值、非等值或者等值与非等值组合类查询，通过如上变换最终可以起到举一反三的作用。
说明：这个例子中可能在一些特殊数据分布场景，最优索引也可能是{f:1, g:1}或者{f:1, g:1, b:1, d:-1}或者{ f:1, g:1, c:1, a:1}，这里我们只考虑大部分通用场景。
3.4 SORT类排序查询常见索引错误创建方法及如何创建最优索引
例如用户有以下两个查询：
这两个查询都不带条件，排序方式不一样，因此很多创建了两个索引{a:1}和{a:-1}，实际上这两个索引中的任何一个都可以满足两种查询要求，验证过程如下：
假设有如下查询：
其中a字段为正序，b字段为反序排序，很多用户直接创建{a:1, b:1}索引，这时候b字段内容就存在内存排序情况。多字段排序索引，如果没有携带查询条件，则最优索引即为排序字段对应索引，这里切记保持每个字段得正反序和sort完全一致，否则可能存在部分字段内存排序的情况，执行计划验证过程如下：
例如如下查询：
该类查询很多人直接创建{a:1, b:1, c:1, d:1}，结果造成内存排序。这种组合查询最优索引=“多字段等值查询最优索引_多字段排序类组合最优索引”，例如该查询：
{ "a" : 3, "b" : 1}等值查询假设a区分度比b高，则对应最优索引为：{a：1, b：1}
{ c:-1, d:1}排序类查询最优索引保持正反序一致，也就是:{ c:-1, d:1}
因此整个查询就是这两个查询对应最优索引拼接，也就是{a:1, b:1, c:-1, d:1}，对应执行计划过程验证如下：
假设有下面的查询：
腾讯云很多用户看到该查询直接创建{a:1, b:1, c:1, d:-1, e:1}索引，发现存在内存排序。等值+非等值+sort排序组合查询，由于非等值查询右边的字段不能走索引，因此如果把d, e放到c的右边，则d，e字段索引无效。
等值+非等值+sort排序最优索引组合字段顺序为：等值_sort排序_非等值，因此上面查询最优索引为:{a:1, b:1, d:-1, e:1, c:1}。执行计划验证过程如下：
例如如下查询：
上面组合很多人直接创建{b:1, d:1, c:1, a:1, e:1}，该索引创建后还是会扫表和内存排序，实际上OR+SORT组合查询可以转换为下面两个查询：
所以这个复杂查询就可以拆分为等值组合查询+sort排序查询，拆分为上面的两个查询，这样我们只需要同时创建查询2和查询3对应最优索引即可。该查询最终拆分后对应最优索引需要添加如下两个：
{b:1, d:1, e:-1}和{c:1, a:1, e:-1}
非最优索引和最优索引执行计划验证过程如下：
OR+SORT类查询，最终可以《参考前面的OR类查询常见索引错误创建方法》把OR查询转换为多个等值、非等值或者等值与非等值组合查询，然后与sort排序对应索引字段拼接。例如下面查询：
拆分后的两个查询组成or关系，如下：
如上，查询1 = or: [查询2， 查询3]，因此只需要创建查询2和查询3两个最优索引即可满足查询1要求，查询2和查询3最优索引可以参考前面《or类查询常见索引错误创建方法》，该查询最终需要创建如下两个索引：
{f:1, g:1, b:1, d:1, e:-1}和{ f:1, g:1, c:1, a:1, e:-1}
说明：这个例子中可能在一些特殊数据分布场景，最优索引也可能是{f:1, g:1}或者{f:1, g:1, b:1, d:1, e:-1}或者{ f:1, g:1, c:1, a:1, e:-1}，这里我们只考虑通用场景。
3.5 避免创建太多无用索引及无用索引分析方法
在腾讯云上，我们还发现另外一个问题，很多实例存在大量无用索引，无用索引会引起以下问题：
存储成本增加
没增加一个索引，MongoDB内核就会创建一个index索引文件，记录该表的索引数据，造成存储成本增加。
影响写性能
用户没写入一条数据，就会在对应索引生成一条索引KV，实现索引与数据的一一对应，索引KV数据写入Index索引文件过程加剧写入负载。
影响读性能
MongoDB内核查询优化器原理是通过候选索引快速定位到满足条件的数据，然后采样评分。如果满足条件的候选索引越多，整个评分过程就会越长，增加内核选择最优索引的流程。
下面以一个真实线上实例为例，说明如何找出无用索引：
MongoDB默认提供有索引统计命令来获取各个索引命中的次数，该命令如下：
该聚合输出中的几个核心指标信息如下表：
上表中的ops代表命中次数，如果命中次数为0或者很小，说明该索引很少被选为最优索引使用，因此可以认为是无用索引，可以考虑删除。
说明：
本文总结的《最优索引规则大全》中的规则适用于绝大部分查询场景，但是一些特殊数据分布场景可能会有一定偏差，请根据实际数据分布进行查询计划分析。
DBbrain for MongoDB
最后，本文中所介绍的优化原理即将集成到腾讯云DBbrain for MongoDB的智能索引推荐(规则+代价计算)功能中，届时可帮助用户一键优化索引，无需亲自反复推敲验证，欢迎体验。
腾讯云MongoDB当前服务于 游戏 、电商、社交、教育、新闻资讯、金融、物联网、软件服务等多个行业；MongoDB团队(简称CMongo)致力于对开源MongoDB内核进行深度研究及持续性优化(如百万库表、物理备份、免密、审计等)，为用户提供高性能、低成本、高可用性的安全数据库存储服务。后续持续分享MongoDB在腾讯内部及外部的典型应用场景、踩坑案例、性能优化、内核模块化分析。
﹀
﹀
﹀
叮咚买菜自建MangoDB上腾讯云实践
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）