1
nullcc 2015-10-23 11:47:04 +08:00
find({})是全集合扫描了, explain()一下就能看到 nscanned 字段是整个集合的总文档数,慢是正常的,有索引,一般 B/B+ tree 搜索,时间复杂度肯定要大大小于全文档扫描
|
2
nullcc 2015-10-23 11:54:29 +08:00
上面说的有点问题,我没加 limit , shell 上跑貌似没 LZ 说的问题, 200W 左右数据量
|
3
vlike OP @nullcc
应该是数据库有问题,但我却查不出什么问题。 我测试时开了两个分片 A , B 。他们的数据量相当各 150W 左右,分别在两个配置一样的虚拟机内分别安装的 A 跟 B 。 B 执行上述命令很快返回,但 A 要 30 秒左右,并且 CPU 很高。 试过 db.repairDatabase(),不过没有效果。 开启了慢查询记录,但似乎我看不出什么有用的信息: { "op": "query", "ns": "Book.test", "query": { }, "ntoreturn": 1, "ntoskip": 0, "nscanned": 0, "nscannedObjects": 1, "keyUpdates": 0, "writeConflicts": 0, "numYield": 1, "locks": { "Global": { "acquireCount": { "r": NumberLong(4) } }, "Database": { "acquireCount": { "r": NumberLong(2) } }, "Collection": { "acquireCount": { "r": NumberLong(2) } } }, "nreturned": 1, "responseLength": 67, "millis": 35616, "execStats": { "stage": "PROJECTION", "nReturned": 1, "executionTimeMillisEstimate": 35340, "works": 2, "advanced": 1, "needTime": 1, "needFetch": 0, "saveState": 1, "restoreState": 1, "isEOF": 0, "invalidates": 0, "transformBy": { "text": 0 }, "inputStage": { "stage": "COLLSCAN", "filter": { "$and": [ ] }, "nReturned": 1, "executionTimeMillisEstimate": 35340, "works": 2, "advanced": 1, "needTime": 1, "needFetch": 0, "saveState": 1, "restoreState": 1, "isEOF": 0, "invalidates": 0, "direction": "forward", "docsExamined": 1 } }, "ts": ISODate("2015-10-23T06:06:39.458Z"), "client": "127.0.0.1", "allUsers": [ ], "user": "" } |