很多人第一次接觸 MongoDB都是在項目里被字段老變、表結構改不動這件事逼過來的。我最開始也一樣拿著關系型數(shù)據(jù)庫的思維去用建了一堆看起來像表的集合寫出來的查詢?nèi)頀呙钄?shù)據(jù)量一上萬就開始卡。后來花了些時間把文檔模型、索引和執(zhí)行計劃這幾塊重新捋了一遍才發(fā)現(xiàn)這東西上手門檻確實低但想用得舒服完全是另一回事。這篇就按我自己帶人、自己踩坑的順序把 MongoDB 從裝好到能寫出一條像樣的查詢這條鏈路完整走一遍重點講清楚每個操作為什么這么寫而不是把官方文檔翻譯一遍。適合剛接手一個 MongoDB 項目、或者準備在下一個需求里引入它的朋友不管你是寫后端還是做數(shù)據(jù)分析跟著走一遍基本能跑通。1. 先把文檔模型這件事想明白別拿它當關系庫用我在代碼評審里見過太多次這種情況一個集合里全是{_id, type, ...}這種結構然后靠type字段去區(qū)分不同實體查的時候要寫一堆if type order。這就是典型的把關系型思維硬搬過來。文檔模型的核心價值在于把一次業(yè)務讀取需要的數(shù)據(jù)放在一起而不是把數(shù)據(jù)拆得越細越規(guī)范。1.1 一條文檔長什么樣和一行記錄差在哪里關系庫里一行記錄的所有字段都是扁平標量復雜結構必須拆表。MongoDB 的一條文檔本質(zhì)是一個 BSON 對象字段值可以是字符串、數(shù)字、日期也可以直接是嵌套對象或者數(shù)組。舉個實際點的例子一個商品在關系庫里大概要拆成商品表、SKU 表、屬性表三張而在文檔模型里完全可以是一條{ _id: ObjectId(...), title: 某款機械鍵盤, price: 399, tags: [辦公, 無線, 靜音], specs: { switchType: 紅軸, layout: 87鍵, weight: 780 }, skus: [ { code: K87-W, color: 白, stock: 120 }, { code: K87-B, color: 黑, stock: 45 } ], createdAt: ISODate(2024-03-11T08:20:00Z) }讀一個商品詳情一條findOne就夠了不需要三次 join。這就是文檔模型最直接的收益讀路徑變短。代價是寫入時可能要更新整個文檔以及同一份數(shù)據(jù)在不同文檔里可能出現(xiàn)冗余。這個取舍后面第 6 節(jié)會展開講。這里有個細節(jié)容易被忽略_id默認是ObjectId它不是一個隨機串結構上包含 4 字節(jié)時間戳、5 字節(jié)隨機值、3 字節(jié)自增計數(shù)器。這意味著_id本身就帶創(chuàng)建時間信息你甚至可以用ObjectId(...).getTimestamp()反推文檔的創(chuàng)建時間。我在做數(shù)據(jù)排查的時候經(jīng)常用這招比額外加一個createdAt字段還快。1.2 什么場景適合什么場景別硬上不是所有項目都該上 MongoDB。我自己的判斷標準大概是這樣場景特征更適合的選擇原因字段結構頻繁變化每個租戶字段還不一樣文檔模型不需要頻繁 DDL應用層控制結構讀多寫少一次讀取要拼好幾張表文檔模型內(nèi)嵌減少 join讀放大明顯強事務、多表強一致性轉賬類關系型跨文檔事務開銷大邏輯復雜大量多對多、需要靈活任意維度關聯(lián)查詢關系型文檔模型對多對多不友好日志、埋點、內(nèi)容、商品、配置文檔模型結構松、寫入吞吐要求高報表類復雜聚合、窗口函數(shù)關系型或專用分析庫聚合管道能力有限復雜 SQL 更順手一句話總結讀模式相對固定、寫模式靈活多變的結構適合文檔模型。如果你的查詢需求是任意維度隨便組合那關系庫的優(yōu)化器還是更靠譜。2. 環(huán)境從零跑起來安裝、啟動到第一次握手裝 MongoDB 這件事本身不難難的是新手容易在幾個環(huán)節(jié)卡住服務沒起來、端口被占、認證沒配好、連上了卻沒權限。我把這條鏈路拆細一點。2.1 本地起一個實例的幾種方式最省事的是容器方式一條命令搞定數(shù)據(jù)掛到本地目錄刪了容器數(shù)據(jù)還在docker run -d \ --name mongo-dev \ -p 27017:27017 \ -v /data/mongo:/data/db \ -e MONGO_INITDB_ROOT_USERNAMEadmin \ -e MONGO_INITDB_ROOT_PASSWORDdevpass123 \ mongo:7.0注意MONGO_INITDB_ROOT_USERNAME這個環(huán)境變量只有在數(shù)據(jù)目錄為空、首次初始化時才生效。我見過有人把數(shù)據(jù)目錄掛到已有數(shù)據(jù)的路徑然后發(fā)現(xiàn)環(huán)境變量里的賬號密碼根本沒建上連都連不進去排查半天。要么用全新的空目錄要么手動進容器建用戶。如果用包管理器安裝Linux 上裝完之后默認是mongod服務用systemctl start mongod啟動配置文件一般在/etc/mongod.conf默認只監(jiān)聽127.0.0.1。這個默認值是有意為之的不要在沒配認證的情況下把bindIp改成0.0.0.0我在一些內(nèi)網(wǎng)環(huán)境里見過裸奔的實例任何人都能連上去刪庫。配置文件里幾個值得改的點net: port: 27017 bindIp: 127.0.0.1 storage: dbPath: /var/lib/mongo wiredTiger: engineConfig: cacheSizeGB: 2cacheSizeGB默認會吃掉可用內(nèi)存的一半減 1G。在容器里如果沒設內(nèi)存限制它可能按宿主機的內(nèi)存來算結果被 OOM kill。容器部署時建議顯式設置這個值一般給容器內(nèi)存的 50% 到 60%。2.2 連接串里的每個參數(shù)都值得看一遍連接串看著簡單但每個參數(shù)背后都有含義mongodb://admin:devpass123localhost:27017/appdb?authSourceadminmaxPoolSize50retryWritestrueauthSourceadmin認證庫。用戶建在哪個庫這里就寫哪個。建在admin庫卻連業(yè)務庫時忘了加這個參數(shù)報的錯是Authentication failed很容易誤判成密碼錯。maxPoolSize連接池上限默認 100。小服務給 20 到 50 就夠給太大會把數(shù)據(jù)庫連接數(shù)打滿。retryWritestrue遇到網(wǎng)絡抖動或主節(jié)點切換時自動重試一次。副本集環(huán)境建議開著單機開了也無害。要注意retryWrites不是萬能的它只對冪等或可重試的寫操作生效而且是在驅動層重試如果第一次寫其實成功了只是響應丟了重試可能造成重復寫入。所以業(yè)務上需要唯一性的字段索引該建還是要建。2.3 用 mongosh 還是圖形工具mongosh是官方現(xiàn)在的命令行客戶端語法上是 JS 環(huán)境可以寫循環(huán)、可以定義變量調(diào)試的時候非常順手。圖形工具比如一些可視化客戶端適合看數(shù)據(jù)和臨時改兩條記錄但復雜查詢還是命令行快。一個我常用的技巧是在 mongosh 里定義幾個快捷函數(shù)// 查看當前庫所有集合及大小 db.getCollectionNames().forEach(function(c) { var s db.getCollection(c).stats(); print(c \t s.count \t (s.size / 1024 / 1024).toFixed(2) MB); });排查哪個集合在瘋漲的時候這行比翻監(jiān)控面板快多了。3. 把增刪改查寫成肌肉記憶操作符才是重點CRUD 誰都會寫但寫得好不好差別全在對操作符的理解上。我見過太多人把讀出來、在應用里改、再整體寫回去當成標準做法結果并發(fā)一上來就丟更新。3.1 插入單條、批量與順序的取舍db.orders.insertOne({ orderNo: A1001, amount: 199, status: paid }); db.orders.insertMany([ { orderNo: A1002, amount: 88, status: paid }, { orderNo: A1003, amount: 320, status: unpaid } ], { ordered: false });ordered: false這個參數(shù)很關鍵。默認是有序插入一旦中間某條失敗比如唯一索引沖突后面的全部不執(zhí)行。設為false之后失敗的跳過成功的照常寫入返回值里會帶上失敗的索引列表。批量導入數(shù)據(jù)的場景基本都應該關掉有序否則一條臟數(shù)據(jù)能讓整批任務中斷。但要注意ordered: false下驅動可能會并發(fā)寫多個分片或節(jié)點失敗的那條不會自動重試你的代碼需要自己處理返回值里的writeErrors。3.2 查詢條件、投影和游標db.orders.find( { status: paid, amount: { $gte: 100 } }, { orderNo: 1, amount: 1, _id: 0 } ).sort({ amount: -1 }).limit(20);投影里_id: 0是為了省字節(jié)。數(shù)據(jù)量大、字段多的時候只取需要的字段能讓網(wǎng)絡傳輸量降一個數(shù)量級。我做過一個對比一個文檔平均 4KB只投影出 3 個字段之后只有 200 字節(jié)左右20 倍差距。游標這塊有個新手常犯的問題遍歷大數(shù)據(jù)集時直接find()然后toArray()內(nèi)存直接爆。正確做法是用游標迭代const cursor db.orders.find({ status: paid }).batchSize(500); while (cursor.hasNext()) { /* 逐條處理 */ }batchSize控制每次從服務端拉多少條默認 101 條第一批發(fā)完后就按 16MB 限制取。對于導出類任務把它設成幾百到一千比較均衡。3.3 更新操作符才是核心這是我見過最多問題的地方。下面這種寫法在并發(fā)下必丟更新// 錯誤示范讀-改-寫 const doc db.accounts.findOne({ _id: 1 }); db.accounts.updateOne({ _id: 1 }, { $set: { balance: doc.balance - 100 } });兩個人同時讀到balance 500各自減 100 寫回最后是 400 而不是 300。正確姿勢是用$inc讓數(shù)據(jù)庫做原子運算db.accounts.updateOne( { _id: 1, balance: { $gte: 100 } }, { $inc: { balance: -100 }, $set: { updatedAt: new Date() } } );條件里帶上balance: { $gte: 100 }是樂觀鎖的思路余額不足時matchedCount為 0業(yè)務層就知道扣款失敗。這樣既保證了原子性又避免了超扣。幾個高頻操作符的語義要分清操作符作用注意點$set設置字段值字段不存在會創(chuàng)建$unset刪除字段值是占位符寫什么都行$inc數(shù)值增減字段必須存在或是數(shù)字否則報錯$push數(shù)組末尾追加可配合$each批量加$addToSet數(shù)組去重追加元素多時性能下降明顯$pull按條件移除數(shù)組元素支持條件表達式$setOnInsert僅插入時設置必須配合upsert: trueupsert: true是個好幫手先查后插的兩步操作可以合并成一步db.users.updateOne( { openId: u_123 }, { $set: { nickname: 老王 }, $setOnInsert: { createdAt: new Date() } }, { upsert: true } );注意$set和$setOnInsert不能作用于同一個字段否則會報沖突。3.4 刪除要謹慎軟刪除更常見物理刪除deleteMany在線上環(huán)境我建議慎用尤其是沒有備份的情況下。大多數(shù)業(yè)務場景用軟刪除更穩(wěn)加一個deletedAt字段查詢時帶上deletedAt: null。如果確實要物理刪除先查一遍確認范圍// 先看會刪掉多少條 db.logs.countDocuments({ createdAt: { $lt: new Date(2024-01-01) } }); // 確認無誤再刪分批刪避免長鎖 db.logs.deleteMany({ createdAt: { $lt: new Date(2024-01-01) } });單次刪幾十萬條會長時間占用寫鎖更好的方式是分批每次刪 5000 條循環(huán)執(zhí)行中間 sleep 一小會。4. 索引和執(zhí)行計劃數(shù)據(jù)漲到百萬級之后的分水嶺前面那些操作在幾千條數(shù)據(jù)的時候都飛快任何寫法都能跑。等到集合上百萬差別就出現(xiàn)了有的查詢 5 毫秒有的一分半。分水嶺就是索引。4.1 復合索引的最左前綴原則db.orders.createIndex({ status: 1, createdAt: -1 });這條復合索引能支持的查詢是status單獨查、status createdAt組合查。但單獨用createdAt查走不了因為status在最左邊跳不過去。這就是最左前綴原則和關系庫一樣。字段順序怎么定我一般按 ESR 原則Equality等值在前Sort排序在中Range范圍在后。比如查已支付訂單、按時間倒序、金額大于 100db.orders.find({ status: paid, amount: { $gt: 100 } }).sort({ createdAt: -1 });理論上最理想的是{ status: 1, createdAt: -1, amount: 1 }。為什么把范圍條件放最后因為范圍條件一旦匹配后面的字段就無法再用索引做精確跳轉了。當然實際場景里排序字段和范圍字段的順序還要結合數(shù)據(jù)分布測試不要迷信理論。4.2 用 explain 看它到底走了哪條路索引建完不代表用上了。驗證方式是explaindb.orders.find({ status: paid }).sort({ createdAt: -1 }) .explain(executionStats);重點看幾個字段winningPlan.stageCOLLSCAN表示全表掃描IXSCAN表示走了索引FETCH表示還要回表取文檔。totalDocsExamined掃描文檔數(shù)。如果遠大于返回條數(shù)索引效果很差。totalKeysExamined掃描索引鍵數(shù)。executionTimeMillis執(zhí)行耗時。一個健康的查詢totalDocsExamined應該接近返回條數(shù)。如果看到nReturned: 20但totalDocsExamined: 200000說明索引方向不對或者查詢條件本身不具選擇性。4.3 幾個讓索引失效的典型寫法寫法問題改法{ name: /abc/ }前置通配無法走索引改成前綴匹配/^abc/或上全文索引{ age: { $ne: 30 } }不等條件選擇性差盡量用等值 范圍組合查詢字段做了運算索引鍵無法參與匹配把運算挪到應用層或建表達式索引數(shù)組字段上建普通索引后按元素數(shù)查索引覆蓋不到需要$size的場景考慮冗余計數(shù)字段索引字段類型混用字符串和數(shù)字類型不匹配不命中統(tǒng)一寫入類型必要時加校驗還有一個坑是索引建太多。每加一個索引寫入時就要多維護一棵 B 樹。我見過一個集合上建了十幾個索引寫入 QPS 直接腰斬。原則是先看慢查詢?nèi)罩菊页稣嬲哳l的查詢模式再針對性建索引定期用$indexStats檢查索引使用次數(shù)長期為 0 的果斷刪掉。db.orders.aggregate([{ $indexStats: {} }]);這個命令會返回每個索引的accesses.ops一目了然。5. 聚合管道把統(tǒng)計邏輯從應用層搬回來以前我特別愛在應用層做統(tǒng)計查出一堆文檔然后 for 循環(huán)累加。后來發(fā)現(xiàn)數(shù)據(jù)量一上來網(wǎng)絡傳輸和內(nèi)存占用都受不了而且代碼又長又難維護。聚合管道就是把這類邏輯下推到數(shù)據(jù)庫側。5.1 管道的執(zhí)行順序決定了性能聚合管道是一串 stage 依次執(zhí)行每個 stage 的輸出是下一個的輸入。順序至關重要$match和$limit一定要盡早db.orders.aggregate([ { $match: { status: paid, createdAt: { $gte: ISODate(2024-01-01) } } }, { $group: { _id: $userId, total: { $sum: $amount }, cnt: { $sum: 1 } } }, { $match: { total: { $gte: 1000 } } }, { $sort: { total: -1 } }, { $limit: 50 } ]);如果把$match放在$group后面前面就要對全量數(shù)據(jù)處理一遍可能慢幾十倍。能過濾的先過濾能少的先少這是寫聚合管道的第一原則。另外第一個$match如果命中了索引整個管道都會受益。所以聚合查詢的入口過濾條件要和索引對齊寫完記得用explain看一下。5.2 分組、展開和關聯(lián)$group里最常用的是$sum、$avg、$max、$min還可以用$push把分組內(nèi)的值收集成數(shù)組{ $group: { _id: $category, prices: { $push: $price } } }$unwind用來把數(shù)組拆成多條處理一條訂單多個商品這種結構特別方便db.orders.aggregate([ { $unwind: $items }, { $group: { _id: $items.sku, sold: { $sum: $items.qty } } }, { $sort: { sold: -1 } } ]);$lookup相當于左連接但它在大數(shù)據(jù)量下是性能殺手因為每個輸入文檔都要去目標集合查一次。如果目標集合的關聯(lián)字段上有索引還好沒有索引就是災難。我的建議是能靠內(nèi)嵌解決的關聯(lián)就別用$lookup。5.3 聚合的內(nèi)存限制和落盤聚合管道默認每個 stage 最多用 100MB 內(nèi)存超了直接報錯。大數(shù)據(jù)量分組要開啟落盤db.orders.aggregate(pipeline, { allowDiskUse: true });開啟之后會寫臨時文件速度慢一些但不會失敗。生產(chǎn)環(huán)境跑報表類聚合這個參數(shù)基本是必開的。還有一點$group的_id如果基數(shù)特別大比如按用戶 ID 分組幾千萬用戶內(nèi)存和臨時文件都會吃緊。這種場景我一般會先按時間窗口切分分批聚合再合并結果比一次性硬跑靠譜。6. 數(shù)據(jù)建模和幾個新手最容易翻車的地方前面都是操作層面的事真正決定項目后期好不好維護的是數(shù)據(jù)建模。這塊沒有標準答案但有些坑是共通的。6.1 內(nèi)嵌還是引用看讀寫比例這是文檔建模最核心的決策。判斷依據(jù)其實就一句話這份子數(shù)據(jù)是不是總跟著主數(shù)據(jù)一起讀而且數(shù)量有上限。適合內(nèi)嵌的情況訂單里的商品明細、文章里的標簽、用戶設置里的偏好項。這些數(shù)據(jù)量有限幾十條以內(nèi)且讀主數(shù)據(jù)時基本都要一起讀。適合引用的情況用戶和訂單、商品和評論。這類數(shù)據(jù)會無限增長或者需要獨立查詢內(nèi)嵌進去會導致文檔不斷變大最終撞上 16MB 的單文檔上限。一個真實踩過的坑某項目把用戶的所有操作日志內(nèi)嵌到用戶文檔里一開始沒問題跑了一年之后單個文檔漲到十幾 MB更新開始報錯查詢也越來越慢。后來拆成獨立集合按userId索引才解決。數(shù)組字段一定要問自己這個數(shù)組會不會無限增長。會就必須拆出去。6.2 無模式不等于不用設計MongoDB 不強制 schema不代表可以隨便寫。同一個集合里字段名一會兒userId一會兒user_id一會兒字符串一會兒數(shù)字后期查詢能把你逼瘋。我的做法是在應用層用統(tǒng)一的模型定義很多語言的驅動都支持 schema 校驗同時在集合上開 validatordb.createCollection(orders, { validator: { $jsonSchema: { bsonType: object, required: [orderNo, amount, status], properties: { orderNo: { bsonType: string }, amount: { bsonType: decimal }, status: { enum: [paid, unpaid, refunded] } } } }, validationLevel: moderate });validationLevel: moderate表示已有文檔不校驗、新寫入才校驗避免上線時被歷史數(shù)據(jù)卡住。這個約束看起來麻煩但能擋掉大量低級錯誤。金額字段我特別建議用Decimal128而不是 double浮點數(shù)累加會出現(xiàn)0.1 0.2 0.30000000000000004這種問題財務場景絕對不能接受。6.3 幾個高頻坑的快速清單坑表現(xiàn)處理方式單文檔超 16MB寫入報錯object to insert too large拆集合或改用 GridFS 存大文件正則沒加錨點查詢越來越慢前綴匹配加^或建文本索引時間字段存字符串范圍查詢和排序都不準統(tǒng)一存Date類型skip翻大頁越翻越慢改成基于上一頁最后一條的_id游標翻頁數(shù)組元素無上限文檔膨脹拆子集合主文檔存摘要唯一索引在數(shù)組字段上語義和預期不符想清楚是全數(shù)組唯一還是元素唯一skip翻頁這個坑值得單獨說一下。skip(100000).limit(20)并不是直接跳到第 10 萬條而是先把前面 10 萬條掃一遍再丟掉越往后越慢。正確做法是記住上一頁最后一條的排序字段值下一頁用 lastValue來查db.articles.find({ createdAt: { $lt: lastCreatedAt } }) .sort({ createdAt: -1 }).limit(20);這種方式在任何頁數(shù)下耗時都穩(wěn)定前提是排序字段上有索引。6.4 備份和變更這兩件事別等出事再想最后提兩個運維層面的事。第一是備份mongodump簡單夠用但要注意它是邏輯備份大庫導出很慢而且導出期間的數(shù)據(jù)一致性要靠--oplog保證。數(shù)據(jù)量大的話快照方式更穩(wěn)。第二是索引和字段的變更。給一個千萬級集合加索引如果沒有指定后臺構建會阻塞寫入。新版本雖然默認行為已經(jīng)優(yōu)化但上線前還是應該在預發(fā)環(huán)境用同等數(shù)據(jù)量壓一遍記錄耗時。我吃過一次虧預發(fā)只有十萬條數(shù)據(jù)加索引兩秒完成生產(chǎn)一千多萬條加了四十多分鐘期間接口大面積超時。自此之后任何涉及大集合的變更我都會先拿生產(chǎn)數(shù)據(jù)的抽樣副本跑一遍估算耗時再挑低峰期執(zhí)行。寫了這么多其實 MongoDB 入門真正的門檻不在語法而在兩個思維轉變一是從表結構先行轉到讀取模式先行建模時先想清楚數(shù)據(jù)怎么被讀二是從應用層拼裝轉到數(shù)據(jù)庫側完成索引、聚合、投影這些能力用好了很多邏輯根本不用搬到代碼里。我自己在實際項目里的體會是但凡一個查詢開始變慢第一反應應該是去看explain而不是急著加緩存。緩存能蓋住問題但索引沒建對緩存一失效問題還是原樣回來。