【发布时间】：2014-09-26 09:41:31
【问题描述】：
我有一个非常简单的 mongo 查询，应该使用 _id 索引。 解释计划看起来不错：
> db.items.find({ deleted_at: null, _id: ObjectId('541fd8016d792e0804820100') }).sort({ positions: 1 }).explain()
{
"cursor" : "BtreeCursor _id_",
"isMultiKey" : false,
"n" : 1,
"nscannedObjects" : 1,
"nscanned" : 1,
"nscannedObjectsAllPlans" : 6,
"nscannedAllPlans" : 7,
"scanAndOrder" : true,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 0,
"indexBounds" : {
"_id" : [
[
ObjectId("541fd8016d792e0804820100"),
ObjectId("541fd8016d792e0804820100")
]
]
},
"server" : "mydbserver:27017",
"filterSet" : false
}
但是当我执行查询时，它会在 100-800 毫秒内执行：
> db.items.find({ deleted_at: null, _id: ObjectId('541fd8016d792e0804820100') }).sort({ positions: 1 })
2014-09-26T12:34:00.279+0300 [conn38926] query mydb.items query: { query: { deleted_at: null, _id: ObjectId('541fd8016d792e0804820100') }, orderby: { positions: 1.0 } } planSummary: IXSCAN { positions: 1 } ntoreturn:0 ntoskip:0 nscanned:70043 nscannedObjects:70043 keyUpdates:0 numYields:1 locks(micros) r:1391012 nreturned:1 reslen:814 761ms
为什么它报告nscanned:70043 nscannedObjects:70043 以及为什么这么慢？
我在 CentOS 6 上使用 MongoDB 2.6.4。
我尝试修复 MongoDB，完全转储/导入，没有帮助。
更新 1
> db.items.find({deleted_at:null}).count()
67327
> db.items.find().count()
70043
我在deleted_at 上没有索引，但我在_id 上有索引。
更新 2（2014-09-26 14:57 EET）
在_id, deleted_at 上添加索引没有帮助，即使explain 也不使用该索引:(
> db.items.ensureIndex({ _id: 1, deleted_at: 1 }, { unique: true })
> db.items.getIndexes()
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "mydb.items"
},
{
"v" : 1,
"unique" : true,
"key" : {
"_id" : 1,
"deleted_at" : 1
},
"name" : "_id_1_deleted_at_1",
"ns" : "mydb.items"
}
]
> db.items.find({ deleted_at: null, _id: ObjectId('541fd8016d792e0804820100') }).sort({ positions: 1 }).explain()
{
"cursor" : "BtreeCursor _id_",
"isMultiKey" : false,
"n" : 1,
"nscannedObjects" : 1,
"nscanned" : 1,
"nscannedObjectsAllPlans" : 7,
"nscannedAllPlans" : 8,
"scanAndOrder" : true,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 0,
"indexBounds" : {
"_id" : [
[
ObjectId("541fd8016d792e0804820100"),
ObjectId("541fd8016d792e0804820100")
]
]
},
"server" : "myserver:27017",
"filterSet" : false
}
更新 3（2014-09-26 15:03:32 EET）
在_id, deleted_at, positions 上添加索引有帮助。但是，以前的案例强制进行完整的收集扫描似乎仍然很奇怪。
> db.items.ensureIndex({ _id: 1, deleted_at: 1, positions: 1 })
> db.items.find({ deleted_at: null, _id: ObjectId('541fd8016d792e0804820100') }).sort({ positions: 1 }).explain()
{
"cursor" : "BtreeCursor _id_1_deleted_at_1_positions_1",
"isMultiKey" : false,
"n" : 1,
"nscannedObjects" : 1,
"nscanned" : 1,
"nscannedObjectsAllPlans" : 3,
"nscannedAllPlans" : 3,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 0,
"indexBounds" : {
"_id" : [
[
ObjectId("541fd8016d792e0804820100"),
ObjectId("541fd8016d792e0804820100")
]
],
"deleted_at" : [
[
null,
null
]
],
"positions" : [
[
{
"$minElement" : 1
},
{
"$maxElement" : 1
}
]
]
},
"server" : "myserver:27017",
"filterSet" : false
}
【问题讨论】：
-
您是否在字段
deleted_at上建立了索引？您可以在db.item.find({deleted_at:null}).count()上进行测试以与70043进行比较。 -
我用计数更新了我的问题
-
为什么要使用排序，当扫描条目的数量最多为 1 时，因为您是基于唯一的 id 进行过滤？
-
排序部分是使用 mongoid ruby gem 生成的。没有排序部分，它的工作速度很快。
-
我有一个模型类 Item include Mongoid::Document include Mongoid::Paranoia self.default_scoping = -> { where(deleted_at: nil).asc(:positions) } end
标签： mongodb