mongodb - 在 MongoDB 查询优化器中选择完美索引的冲突

Question

我的问题与 MongoDB 的查询优化器以及它如何选择要使用的完美索引有关。我意识到在某些情况下，优化器不会选择完美的现有索引，而是继续使用足够接近的索引。

考虑拥有一个简单的数据集，例如:

{ "_id" : 1, "item" : "f1", "type" : "food", "quantity" : 500 }
{ "_id" : 2, "item" : "f2", "type" : "food", "quantity" : 100 }
{ "_id" : 3, "item" : "p1", "type" : "paper", "quantity" : 200 }
{ "_id" : 4, "item" : "p2", "type" : "paper", "quantity" : 150 }
{ "_id" : 5, "item" : "f3", "type" : "food", "quantity" : 300 }
{ "_id" : 6, "item" : "t1", "type" : "toys", "quantity" : 500 }
{ "_id" : 7, "item" : "a1", "type" : "apparel", "quantity" : 250 }
{ "_id" : 8, "item" : "a2", "type" : "apparel", "quantity" : 400 }
{ "_id" : 9, "item" : "t2", "type" : "toys", "quantity" : 50 }
{ "_id" : 10, "item" : "f4", "type" : "food", "quantity" : 75 }

然后想发出如下查询:

db.inventory.find({"type": "food","quantity": {$gt: 50}})

我继续创建以下索引:

db.inventory.ensureIndex({"quantity" : 1,  "type" : 1})

cursor.explain() 的统计数据证实该索引具有以下性能:(“n”:4，“nscannedObjects”:4，“nscanned”:9)。它扫描了比完全匹配数更多的索引。考虑到“类型”是具有识别匹配的更高选择性属性这一事实，创建以下索引肯定更好:

db.inventory.ensureIndex({ "type" : 1, "quantity" : 1})

统计数据还证实该索引性能更好:(“n”:4，“nscannedObjects”:4，“nscanned”:4)。这意味着第二个索引需要扫描与匹配文档完全相同数量的索引。

但是，我观察到如果我不删除第一个索引，查询优化器会继续使用第一个索引，尽管创建了更好的索引。

根据文档，每次创建新索引时，查询优化器都会将其视为制定查询计划，但我在这里看不到这种情况。

谁能解释查询优化器的真正工作原理？

Answer 1

Considering the fact that "type" is a higher selective attribute

索引选择性是一个非常重要的方面，但在这种情况下，请注意您使用的是类型相等查询和数量范围查询，这是交换索引顺序的更有说服力的理由，即使选择性是降低。

However, I observed if I don't delete the first index, the query optimizer continues using the first index, although the better index is got created. [...]

MongoDB 查询优化器主要是统计。与大多数 SQL 引擎不同，MongoDB 不会尝试推断什么可能是效率更高或更低的索引。相反，它只是不时地并行运行不同的查询，并记住哪个查询更快。然后将使用更快的策略。 MongoDB 会不时地再次执行并行查询并重新评估策略。

这种方法的一个问题(也可能是造成混淆的原因)是与这么小的数据集可能没有太大区别 - 简单地扫描元素通常比使用任何类型更好如果数据与预取/页面大小/缓存大小和管道长度相比不大，则采用索引或搜索策略。根据经验，包含多达 100 个甚至 1,000 个元素的简单列表通常根本无法从索引中获益。