某一天，監(jiān)控到mongo數(shù)據(jù)庫cpu使用率高了很多，查了一下，發(fā)現(xiàn)是下面這種語句引起的：
db.example_collection.find({
"idField" :
{ "$regex" : "123456789012345678"
} ,
"dateField" :
{ "$regex" : "2019/10/10"
}})
通常，遇到這種情況，我第一反應(yīng)是缺少相關(guān)字段的索引，導(dǎo)致每執(zhí)行一次這種語句都會全表掃描一次。
但是我用explain( )語句分析了下，發(fā)現(xiàn)上面所涉及的兩個(gè)字段idField、dateField是有索引的，并且該語句也是有使用到索引的。如下為explain( )的結(jié)果：
mgset-11111111:PRIMARY> db.example_collection.find({ "idField" : { "$regex" : "123456789012345678"} , "dateField" : { "$regex" : "2019/10/10"}}).explain("queryPlanner")
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "example_db.example_collection",
"indexFilterSet" : false,
"parsedQuery" : {
"$and" : [
{
"idField" : {
"$regex" : "123456789012345678"
}
},
{
"dateField" : {
"$regex" : "2019/10/10"
}
}
]
},
"winningPlan" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"filter" : {
"$and" : [
{
"idField" : {
"$regex" : "123456789012345678"
}
},
{
"dateField" : {
"$regex" : "2019/10/10"
}
}
]
},
"keyPattern" : {
"idField" : 1,
"dateField" : 1
},
"indexName" : "idField_1_dateField_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"idField" : [ ],
"dateField" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"idField" : [
"[\"\", {})",
"[/123456789012345678/, /123456789012345678/]"
],
"dateField" : [
"[\"\", {})",
"[/2019/10/10/, /2019/10/10/]"
]
}
}
},
"rejectedPlans" : [ ]
},
"ok" : 1
}
查看mongo的日志發(fā)現(xiàn)，這種語句執(zhí)行一次就要800~900ms，的確是比較慢。除非數(shù)據(jù)庫cpu核數(shù)很多，要不然只要這種語句每秒并發(fā)稍微高一點(diǎn)，cpu很快就被占滿了。
之后搜索了下，發(fā)現(xiàn)有可能是正則表達(dá)式的問題。原來，雖然該語句的確是使用了索引，但是explain( )語句的輸出中還有一個(gè)字段"indexBounds"，表示執(zhí)行該語句時(shí)所需掃描的索引范圍。說實(shí)話，上面那個(gè)輸出中，我始終沒看明白它那個(gè)索引范圍。上面的語句對idField、dateField這兩個(gè)字段都進(jìn)行了普通的正則表達(dá)式匹配，我猜測它應(yīng)該是掃描了整個(gè)索引樹，所以導(dǎo)致索引并未實(shí)際提升該語句的查詢效率。
我看了下數(shù)據(jù)庫里面的數(shù)據(jù)，發(fā)現(xiàn)idField、dateField這兩個(gè)字段完全沒有必要進(jìn)行正則匹配，進(jìn)行普通的文本匹配就行。將正則匹配操作$regex去掉之后，再分析一下，結(jié)果是這樣的：
mgset-11111111:PRIMARY> db.example_collection.find({ "idField" : "123456789012345678", "dateField" : "2019/10/10"}).explain("queryPlanner")
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "example_db.example_collection",
"indexFilterSet" : false,
"parsedQuery" : {
"$and" : [
{
"idField" : {
"$eq" : "123456789012345678"
}
},
{
"dateField" : {
"$eq" : "2019/10/10"
}
}
]
},
"winningPlan" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"idField" : 1,
"dateField" : 1
},
"indexName" : "idField_1_dateField_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"idField" : [ ],
"dateField" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"idField" : [
"[\"123456789012345678\", \"123456789012345678\"]"
],
"dateField" : [
"[\"2019/10/10\", \"2019/10/10\"]"
]
}
}
},
"rejectedPlans" : [ ]
},
"ok" : 1
}
可以看到，仍然使用到了索引，并且索引掃描范圍是僅限于一個(gè)值的。
后來跟開發(fā)人員確認(rèn)了下，該語句確實(shí)沒必要使用正則匹配，就讓他把正則匹配去掉了。之后就沒有再出現(xiàn)問題了，mongo慢日志中也未再出現(xiàn)該語句。
總結(jié)
以上所述是小編給大家介紹的解決正則表示式匹配($regex)引起的一次mongo數(shù)據(jù)庫cpu占用率高的問題，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時(shí)回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！
如果你覺得本文對你有幫助，歡迎轉(zhuǎn)載，煩請注明出處，謝謝！
您可能感興趣的文章:- 中文正則表達(dá)式匹配問題之正則表達(dá)式中文匹配使用方法
- Python正則表達(dá)式匹配日期與時(shí)間的方法
- Python正則表達(dá)式匹配數(shù)字和小數(shù)的方法
- python字符串中匹配數(shù)字的正則表達(dá)式
- Python正則表達(dá)式匹配和提取IP地址
- 一個(gè)正則表達(dá)式導(dǎo)致CPU 利用率居高不下
