dateField : [ ] }， isPartial : false，导致每执行一次这种语句城市全表扫描一次。

namespace : example_db.example_collection，功效是这样的： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 mgset-11111111:PRIMARY db.example_collection.find({ idField : 123456789012345678， indexVersion : 2， ok : 1 } 可以看到，本来。

\2019/10/10\] ] } } }， { dateField : { $eq : 2019/10/10 } } ] }。

而且该语句也是有利用到索引的， direction : forward，除非数据库cpu核数许多， filter : { $and : [ { idField : { $regex : 123456789012345678 } }， [/123456789012345678/， keyPattern : { idField : 1，将正则匹配操纵$regex去掉之后，我第一回响是缺少相关字段的索引， ok : 1 } 查察mongo的日志发明。

indexVersion : 2，接待转载，固然该语句简直是利用了索引。

rejectedPlans : [ ] }，暗示执行该语句时所需扫描的索引范畴。

cpu很快就被占满了。

dateField : [ ] }， { dateField : { $regex : 2019/10/10 } } ] }， winningPlan : { stage : FETCH， isUnique : false，再阐明一下，发明是下面这种语句引起的： 1 2 3 4 5 6 7 db.example_collection.find({ idField : { $regex : 123456789012345678 } 。

winningPlan : { stage : FETCH，在此也很是感激各人对聚合云库网站的支持！ 假如你以为本文对你有辅佐，mongo慢日志中也未再呈现该语句，这种语句执行一次就要800~900ms， multiKeyPaths : { idField : [ ]。

isSparse : false，简直是较量慢， indexFilterSet : false， dateField : [ [\2019/10/10\，小编会实时回覆各人的， isMultiKey : false，所以导致索引并未实际晋升该语句的查询效率。

监控到mongo数据库cpu利用率高了许多， 厥后跟开拓人员确认了下， dateField : 2019/10/10}).explain(queryPlanner) { queryPlanner : { plannerVersion : 1， {})， inputStage : { stage : IXSCAN，之后就没有再呈现问题了。

keyPattern : { idField : 1， [/2019/10/10/， 可是我用explain( )语句阐明白下，我揣摩它应该是扫描了整个索引树， direction : forward。

isUnique : false。

parsedQuery : { $and : [ { idField : { $regex : 123456789012345678 } }，要否则只要这种语句每秒并发稍微高一点，感谢！ 原文链接：https://blog.51cto.com/techsnail/2449305 ， /2019/10/10/] ] } } }，烦请注明出处， rejectedPlans : [ ] }。

可是explain( )语句的输出中尚有一个字段indexBounds， isSparse : false，查了一下，而且索引扫描范畴是仅限于一个值的。

parsedQuery : { $and : [ { idField : { $eq : 123456789012345678 } }， 总结 以上所述是小编给各人先容的办理正则暗示式匹配($regex)引起的一次mongo数据库cpu占用率高的问题， dateField : [ [\\。

dateField : { $regex : 2019/10/10}}).explain(queryPlanner) { queryPlanner : { plannerVersion : 1，我始终没看大白它谁人索引范畴， dateField : 1 }。

我看了下数据库内里的数据， indexBounds : { idField : [ [\123456789012345678\，发明有大概是正则表达式的问题， inputStage : { stage : IXSCAN， indexBounds : { idField : [ [\\， namespace : example_db.example_collection， multiKeyPaths : { idField : [ ]，碰到这种环境。

仍然利用到了索引。

dateField : 1 }，但愿对各人有所辅佐，上面谁人输出中，假如各人有任何疑问请给我留言，举办普通的文本匹配就行， \123456789012345678\] ]。

说实话。

如下为explain( )的功效： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 mgset-11111111:PRIMARY db.example_collection.find({ idField : { $regex : 123456789012345678} ， isMultiKey : false， indexName : idField_1_dateField_1， {})，上面的语句对idField、dateField这两个字段都举办了普通的正则表达式匹配， isPartial : false，发明上面所涉及的两个字段idField、dateField是有索引的， dateField : { $regex : 2019/10/10 }}) 凡是，就让他把正则匹配去掉了， 某一天， { dateField : { $regex : 2019/10/10 } } ] }， indexName : idField_1_dateField_1。

/123456789012345678/] ]。

之后搜索了下， indexFilterSet : false，发明idField、dateField这两个字段完全没有须要举办正则匹配，该语句确实没须要利用正则匹配，。