解决正则表示式匹配($regex)引起的一次mongo数据库cpu占用率高的问题

某一天，监控到mongo数据库cpu使用率高了很多，查了一下，发现是下面这种语句引起的：

1. db.example_collection.find({
2. "idField" :
3. { "$regex" : "123456789012345678"
4. } ,
5. "dateField" :
6. { "$regex" : "2019/10/10"
7. }})

通常，遇到这种情况，我第一反应是缺少相关字段的索引，导致每执行一次这种语句都会全表扫描一次。

但是我用explain( )语句分析了下，发现上面所涉及的两个字段idField、dateField是有索引的，并且该语句也是有使用到索引的。如下为explain( )的结果：

1. mgset-11111111:PRIMARY> db.example_collection.find({ "idField" : { "$regex" :"123456789012345678"} , "dateField" : { "$regex" :"2019/10/10"}}).explain("queryPlanner")
2. {
3. "queryPlanner" : {
4. "plannerVersion" : 1,
5. "namespace" : "example_db.example_collection",
6. "indexFilterSet" : false,
7. "parsedQuery" : {
8. "$and" : [
9. {
10. "idField" : {
11. "$regex" : "123456789012345678"
12. }
13. },
14. {
15. "dateField" : {
16. "$regex" : "2019/10/10"
17. }
18. }
19. ]
20. },
21. "winningPlan" : {
22. "stage" : "FETCH",
23. "inputStage" : {
24. "stage" : "IXSCAN",
25. "filter" : {
26. "$and" : [
27. {
28. "idField" : {
29. "$regex" : "123456789012345678"
30. }
31. },
32. {
33. "dateField" : {
34. "$regex" : "2019/10/10"
35. }
36. }
37. ]
38. },
39. "keyPattern" : {
40. "idField" : 1,
41. "dateField" : 1
42. },
43. "indexName" : "idField_1_dateField_1",
44. "isMultiKey" : false,
45. "multiKeyPaths" : {
46. "idField" : [ ],
47. "dateField" : [ ]
48. },
49. "isUnique" : false,
50. "isSparse" : false,
51. "isPartial" : false,
52. "indexVersion" : 2,
53. "direction" : "forward",
54. "indexBounds" : {
55. "idField" : [
56. "[\"\", {})",
57. "[/123456789012345678/, /123456789012345678/]"
58. ],
59. "dateField" : [
60. "[\"\", {})",
61. "[/2019/10/10/, /2019/10/10/]"
62. ]
63. }
64. }
65. },
66. "rejectedPlans" : [ ]
67. },
68. "ok" : 1
69. }

查看mongo的日志发现，这种语句执行一次就要800~900ms，的确是比较慢。除非数据库cpu核数很多，要不然只要这种语句每秒并发稍微高一点，cpu很快就被占满了。

之后搜索了下，发现有可能是正则表达式的问题。原来，虽然该语句的确是使用了索引，但是explain( )语句的输出中还有一个字段"indexBounds"，表示执行该语句时所需扫描的索引范围。说实话，上面那个输出中，我始终没看明白它那个索引范围。上面的语句对idField、dateField这两个字段都进行了普通的正则表达式匹配，我猜测它应该是扫描了整个索引树，所以导致索引并未实际提升该语句的查询效率。

我看了下数据库里面的数据，发现idField、dateField这两个字段完全没有必要进行正则匹配，进行普通的文本匹配就行。将正则匹配操作$regex去掉之后，再分析一下，结果是这样的：

1. mgset-11111111:PRIMARY> db.example_collection.find({ "idField" : "123456789012345678","dateField" : "2019/10/10"}).explain("queryPlanner")
2. {
3. "queryPlanner" : {
4. "plannerVersion" : 1,
5. "namespace" : "example_db.example_collection",
6. "indexFilterSet" : false,
7. "parsedQuery" : {
8. "$and" : [
9. {
10. "idField" : {
11. "$eq" : "123456789012345678"
12. }
13. },
14. {
15. "dateField" : {
16. "$eq" : "2019/10/10"
17. }
18. }
19. ]
20. },
21. "winningPlan" : {
22. "stage" : "FETCH",
23. "inputStage" : {
24. "stage" : "IXSCAN",
25. "keyPattern" : {
26. "idField" : 1,
27. "dateField" : 1
28. },
29. "indexName" : "idField_1_dateField_1",
30. "isMultiKey" : false,
31. "multiKeyPaths" : {
32. "idField" : [ ],
33. "dateField" : [ ]
34. },
35. "isUnique" : false,
36. "isSparse" : false,
37. "isPartial" : false,
38. "indexVersion" : 2,
39. "direction" : "forward",
40. "indexBounds" : {
41. "idField" : [
42. "[\"123456789012345678\", \"123456789012345678\"]"
43. ],
44. "dateField" : [
45. "[\"2019/10/10\", \"2019/10/10\"]"
46. ]
47. }
48. }
49. },
50. "rejectedPlans" : [ ]
51. },
52. "ok" : 1
53. }

可以看到，仍然使用到了索引，并且索引扫描范围是仅限于一个值的。

后来跟开发人员确认了下，该语句确实没必要使用正则匹配，就让他把正则匹配去掉了。之后就没有再出现问题了，mongo慢日志中也未再出现该语句。

总结

以上所述是小编给大家介绍的解决正则表示式匹配($regex)引起的一次mongo数据库cpu占用率高的问题，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对我们网站的支持！
如果你觉得本文对你有帮助，欢迎转载，烦请注明出处，谢谢！