MongoDB中删除集合的操作是非常高效的。如果你的数据生命周期要求周期性删除大容量的文档，那么涉及数据模型时，***把这些文档放在单个集合中。删除一个集合要远比删除集合中所有文档要高效的多。这就类似于在关系型数据库中删除一个表要比删除表中所有的行要更高效。
使用WiredTiger时，删除集合后硬盘空间会自动回收，在MMAPv1中删除集合后空间会自动释放，并会用于新文档的使用。
索引和其他大多数数据库管理系统一样，索引是MongoDB中优化系统性能的重要机制。虽然索引可以把操作的性能提升一个或者多个数量级，但是也会为更新操作、磁盘空间、内存带来不小的负荷。用户任何时候都需要为查询创建合适的索引，但是不应该维护一些没有必要的索引。这对那些需要频繁写入的应用来说尤其重要。
为了操作的简单性，MongoDB Ops Manager 和Cloud Manager平台可以识别丢失的索引并且在不影响应用的情况下自动处理这些索引。
要想了解已存在的索引的使用高效性，可以开启$indexStats这个聚合状态，以便确定索引使用的频率。MongoDB Compass可以把索引情况可视化，让你知道哪些字段使用了索引，他们的索引类型以及使用的频率。
查询优化MongoDB可以自动对查询进行优化并尽可能高效的对查询进行评估。评估通常包括基于谓词的数据选择和基于排序类别的数据排序。查询优化器会周期性的执行多种查询计划并选择性能变现***的索引。这种经验式测试结果会以缓存查询计划存储下来并周期性执行。
MongoDB有explain工具，可以显示每个查询优化前后的信息，包括：
l 文档返回数
l 文档读取数
l 使用了哪个索引
l 查询是否被覆盖，如果覆盖了，则文档不需要读取以返回数据
l 内存排序是否执行了，如果执行了，就意味着加入索引会更高效
l 索引扫描数量
l 查询多长时间可以返回结果（仅限于使用executionStats模式）
l 那个可选择的查询方案被否决了（仅限于allPlansExecution模式）
如果查询的过程花费不到1ms，那么解释计划会显示0ms，通常，在一个优化过的系统中，查询时间就不应该超过1ms。执行计划确定后，之前的缓存查询计划就会放弃，但是多样的测试索引计划还是会重复执行保证***的执行计划会得到实施。查询计划可以在不执行查询的前提下对查询过程进行估算并返回结果，DBA不需要等到查询过程执行完就可以评估使用哪个查询计划。
MongoDB Compass能可视化解释计划的过程，提供查询过程的一些关键信息，比如返回文档数、执行时间、索引使用情况等等。每个执行管道的状态会当做一个节点展现在一个树壮图中，方便查看多节点的解释计划。
如果索引在应用中会经常使用到，就可以设置notablescan选项，当一个查询要扫描整个文档时就抛出一个异常。
归档MongoDB有一个数据库归档器的功能，可以记录数据库操作的细粒度的信息。归档器可以记录所有事件的信息，也可以记录那些执行时间超过设定阈值（默认的是100ms）的事件。归档数据会存放在一个封顶集合中，并可以很方便的查询到相关数据。查询这个集合中的内容往往比翻找日志文件要方便的多。
如果出现慢查询，用MongoDB Ops Manager 和Cloud Manager（后文会提到）可以把归档器的输出信息可视化。Visual Query Profiler为运维人员和DBA提供快速简便的方式来分析具体的查询语句。Visual Query Profiler会展示查询和写入的延时的随时间变化趋势，这。样就可以方便的识别出那些是慢查询以及那些查询的延迟最高。在Ops Manager的图形界面中点击一下鼠标就可以开启归档器，会在一个界面中展示并整合所有节点的信息。
Visual Query Profiler会分析系统推荐的索引，并通过自动滚动索引创建选择性的添加索引。
主索引和辅助索引所有文档都会有一个叫做_id的唯一索引。文档插入时，MongoDB会自动的创建一个_id字段，如果用户没有给这个字段知道值，MongoDB会自动为它分配一个值。所有用户定义的索引都叫做辅助索引。MongoDB支持很多类型的辅助索引，并且可以定义在文档中的任何字段上，包括数组以及子文档。索引类型如下：
l 混合索引
l 地理索引
l 文本搜索索引
l 唯一索引
l 数组索引
l TTL索引
l 稀疏索引
l 偏重索引
l 哈希索引
l 针对不同语言的校对索引（MongoDB3.4以后的版本才有）
索引创建选项