話(huà)說(shuō)今天的一個(gè)小小的查詢(xún)失誤給了我比較深刻的教訓(xùn)，也讓我對(duì)mongo有了更深刻的理解，下面我們來(lái)說(shuō)說(shuō)這個(gè)事情的原委：

我們經(jīng)常使用阿里云子賬號(hào)在DMS上查詢(xún)線(xiàn)上數(shù)據(jù)庫(kù)數(shù)據(jù)，今天也是平常的一次操作

集合：

XXXX_messagebr>數(shù)據(jù)量約 600萬(wàn)

我執(zhí)行了下面的mongo查詢(xún)：

db.XXXX_message.find({"channel_id": "1000000009XXXX700XXXX"}).limit(20);

但是上述語(yǔ)句中的 "channel_id" 字段不存在，真實(shí)字段應(yīng)該是channel(有索引)，屬于失誤操作

在執(zhí)行過(guò)程中，我發(fā)現(xiàn)查詢(xún)時(shí)間很久，于是中斷了查詢(xún)又重試了兩次，還是很久，最后中斷了查詢(xún)，我意識(shí)到我想查的字段可能錯(cuò)了，于是看了下集合索引，使用正確的字段檢索得到結(jié)果

但就在這時(shí)候，一場(chǎng)事故也在悄然醞釀，2分鐘后，阿里云監(jiān)控中心打來(lái)告警電話(huà)，mongo數(shù)據(jù)庫(kù)cpu、iops異常升高

起初并沒(méi)有意識(shí)到是這個(gè)查詢(xún)導(dǎo)致的，還以為是半小時(shí)前發(fā)布的版本可能有問(wèn)題，于是立即回滾了版本并開(kāi)始項(xiàng)目檢查

查了許久，并沒(méi)有查到可能造成本次數(shù)據(jù)庫(kù)異常告警的原因，項(xiàng)目對(duì)該庫(kù)的依賴(lài)的操作的地方非常少。

當(dāng)我們苦苦想不到原因的時(shí)候，我們?nèi)ゲ榱讼孪嚓P(guān)慢sql日志，果然一道耗時(shí)約1800000ms的慢sql日志引起了我們的注意

這時(shí)候我似乎意識(shí)到了點(diǎn)什么，我立馬查阿里云控制臺(tái)查詢(xún)歷史核對(duì)了我剛才查詢(xún)的時(shí)間和數(shù)據(jù)庫(kù)cpu、磁盤(pán)iops異常升高的時(shí)間節(jié)點(diǎn)

完全對(duì)上了，該起事故持續(xù)半小時(shí)左右，那條沒(méi)有被成功中斷的sql也執(zhí)行了半小時(shí)左右

這讓我很震驚，一次控制臺(tái)查詢(xún)居然導(dǎo)致整個(gè)數(shù)據(jù)庫(kù)出現(xiàn)如此嚴(yán)重的問(wèn)題，mongo底層沒(méi)有考慮過(guò)不存在字段查詢(xún)問(wèn)題嗎？

我慢慢平復(fù)心情，仔細(xì)回顧這件事情，我嘗試著從mongo和mysql的底層去理解這個(gè)問(wèn)題

mongo本身是集合型數(shù)據(jù)庫(kù)，意味著每個(gè)集合文檔都可以有自己獨(dú)立的數(shù)據(jù)結(jié)構(gòu)，和mysql等關(guān)系型數(shù)據(jù)庫(kù)的很重要的區(qū)別就是它沒(méi)有固定的表結(jié)構(gòu)，它包容且隨性

當(dāng)在查詢(xún)一個(gè)不存在的字段的時(shí)候，它仍然按照普通查詢(xún)檢索數(shù)據(jù)，這時(shí)候它會(huì)全表掃描，也就是說(shuō)在上述失誤語(yǔ)句中，mongo底層檢索了整個(gè)集合的數(shù)據(jù)集，

遍歷了該集合所有的磁盤(pán)塊，這才導(dǎo)致磁盤(pán)iops升高且cpu升高。

這次經(jīng)歷讓我覺(jué)得我有必要記錄下相關(guān)心得，可能對(duì)于很多高級(jí)技術(shù)人員，這些東西都是很容易理解和規(guī)避的事情，但大多數(shù)人對(duì)此可能并沒(méi)有深刻認(rèn)識(shí)

這次事故讓我對(duì)技術(shù)多了一層敬畏，這有助于我在今后的代碼實(shí)踐和操作中更加謹(jǐn)慎和多一層思考，希望大家以此為戒！此文共勉！

到此這篇關(guān)于一次因mongo查詢(xún)不存在字段引發(fā)的事故記錄的文章就介紹到這了,更多相關(guān)mongo查詢(xún)不存在字段的事故內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！