化：何時(shí)使用、何時(shí)拆分，附 Golang 與 Python 實(shí)戰(zhàn))
我在做技術(shù)方案評審的時(shí)候最怕聽到的一句話就是“先 join 查出來再說后面不行再拆?！闭f這話的人往往沒想過一個(gè)看似簡單的 join在業(yè)務(wù)系統(tǒng)里跑起來之后會(huì)成為慢查詢、連接池耗盡、甚至分庫分表推倒重來的起點(diǎn)。MySQL 的 join 不是不能用而是要看清代價(jià)。今天這篇我把自己在 Golang 和 Python 業(yè)務(wù)項(xiàng)目里處理 join 的經(jīng)驗(yàn)整理出來包括什么時(shí)候該用、什么時(shí)候不該用、拆開之后怎么寫以及踩過的坑。1. 別急著寫 Join先看清 MySQL 的執(zhí)行代價(jià)1.1 一次 Join 背后的執(zhí)行過程MySQL 里最常見的 join 執(zhí)行方式是 Nested Loop Join簡單說就是拿一張表當(dāng)外循環(huán)再拿另一張表當(dāng)內(nèi)循環(huán)一行一行去匹配。比如這條查詢SELECT o.id, u.name, p.title FROM orders o JOIN users u ON o.user_id u.id JOIN products p ON o.product_id p.id WHERE o.status 1MySQL 大概率會(huì)把 orders 當(dāng)成驅(qū)動(dòng)表然后拿著 o.user_id 去 users 表的主鍵索引里逐行查找再拿著 o.product_id 去 products 表里逐行查找。如果兩張表的關(guān)聯(lián)字段都有索引這叫 Index Nested-Loop Join性能尚可。如果其中一張表沒有索引MySQL 就不得不把整張表掃一遍這叫 Simple Nested-Loop Join數(shù)據(jù)量一大基本就是災(zāi)難。這里可以有個(gè)生活化的類比你手上有 10000 張訂單每張訂單要找到對應(yīng)的用戶姓名。如果用戶表有一個(gè)按 ID 排好的電話簿你每次都能直接翻到那一頁速度很快。如果用戶表沒有整理過你每查一個(gè)訂單都要從頭到尾翻一遍電話簿10000 單就是 10000 次全表掃描。所以很多人問“為什么我的 join 這么慢”答案往往不是 join 本身慢而是關(guān)聯(lián)字段上根本沒有索引或者驅(qū)動(dòng)表選錯(cuò)了。到了 MySQL 8.0優(yōu)化器引入了 Hash Join專門處理等值關(guān)聯(lián)且沒有索引的情況。但它也有代價(jià)會(huì)把其中一張表的數(shù)據(jù)加載到內(nèi)存里建哈希表內(nèi)存不夠時(shí)就落盤慢查詢照樣慢。很多人以為升級(jí)到 8.0 就萬事大吉實(shí)際上 Hash Join 只能緩解一部分問題如果你的業(yè)務(wù)表都是千萬級(jí)數(shù)據(jù)join 的代價(jià)依然很可觀。1.2 業(yè)務(wù)系統(tǒng)里的 Join 為什么會(huì)越來越慢很多業(yè)務(wù)系統(tǒng)剛開始用 join 時(shí)很快因?yàn)閿?shù)據(jù)量小。訂單表幾千行用戶表幾百行隨便 join 都是毫秒級(jí)?？上到y(tǒng)跑了半年一年后訂單表漲到幾百萬甚至上千萬用戶表和商品表也膨脹到幾十萬行原來那個(gè)“看著很合理”的 join 就開始露餡了。有幾個(gè)原因疊加在一起會(huì)讓 join 越來越慢第一關(guān)聯(lián)字段的索引因?yàn)閿?shù)據(jù)分布變化而失效。比如你關(guān)聯(lián)的是邏輯刪除字段、狀態(tài)字段這種字段上建索引區(qū)分度太低優(yōu)化器寧愿全表掃也不走索引。第二join 后的結(jié)果集比單表大很多再加上排序、分組、分頁可能要把中間結(jié)果放到臨時(shí)表里消耗大量內(nèi)存和磁盤 IO。第三一旦涉及多表查詢占用的行鎖和事務(wù)時(shí)間也變長在高并發(fā)下很容易拖垮其他簡單查詢。舉一個(gè)我實(shí)際評審過的例子某后臺(tái)訂單導(dǎo)出功能SQL 里 join 了 orders、users、store、payments 四張表還要按用戶手機(jī)號(hào)過濾、按下單時(shí)間排序。上線初期數(shù)據(jù)量 20 萬時(shí)接口響應(yīng) 300ms。到了 300 萬訂單時(shí)響應(yīng)直接變成 6 秒最后把整個(gè)訂單庫的連接池打滿連帶著線上下單都卡了。這種事故幾乎每天都在各種公司的技術(shù)團(tuán)隊(duì)里發(fā)生問題不在 SQL 寫錯(cuò)而在業(yè)務(wù)系統(tǒng)里濫用 join把數(shù)據(jù)庫當(dāng)成了計(jì)算引擎。2. 業(yè)務(wù)系統(tǒng)里濫用 Join 的隱藏成本2.1 表結(jié)構(gòu)耦合導(dǎo)致后續(xù)拆分寸步難行濫用 join 的代價(jià)不只是性能。還有一個(gè)特別隱蔽的問題它在代碼層面把本來可以獨(dú)立的業(yè)務(wù)模塊死死綁在一起。比如用戶服務(wù)、訂單服務(wù)、商品服務(wù)本來應(yīng)該各自維護(hù)自己的數(shù)據(jù)結(jié)果你一條 join 直接把三張表拉在一起查相當(dāng)于在數(shù)據(jù)庫層面提前做了一個(gè)“分布式查詢”但系統(tǒng)架構(gòu)根本沒有準(zhǔn)備好。等你想把訂單服務(wù)拆出來獨(dú)立部署把用戶表挪到另一個(gè)庫時(shí)原來的 SQL 全部作廢?？鐜?join 在 MySQL 原生實(shí)現(xiàn)里是不支持的雖然 FEDERATED 引擎和某些中間件能模擬但性能和一致性都很差。那時(shí)候你只能哭著把所有 join 拆成多次查詢?nèi)缓笮扪a(bǔ)各種緩存和數(shù)據(jù)不一致的坑。所以我在設(shè)計(jì)業(yè)務(wù)系統(tǒng)時(shí)有一個(gè)原則看一條 SQL 就知道這個(gè)模塊的邊界在哪里。如果訂單查詢里 join 了用戶表說明訂單模塊還沒想清楚自己的數(shù)據(jù)邊界。正確做法是把用戶 ID 存到訂單表里需要用戶信息時(shí)通過用戶服務(wù)接口批量獲取而不是直接 join 用戶表。2.2 可用性和擴(kuò)展性受損業(yè)務(wù)系統(tǒng)最怕的不是某個(gè)接口慢而是慢查詢把整個(gè)數(shù)據(jù)庫實(shí)例拖垮。Join 越多數(shù)據(jù)庫 CPU、內(nèi)存、IO 的壓力越大。應(yīng)用服務(wù)可以橫向加機(jī)器數(shù)據(jù)庫卻很難簡單地通過加機(jī)器解決讀壓力尤其是大量 join 疊加后單個(gè)慢查詢就能把連接池吃完其他正常查詢?nèi)颗抨?duì)。我見過一個(gè)比較典型的場景運(yùn)營后臺(tái)一個(gè)多表 join 的大報(bào)表因?yàn)槟程鞌?shù)據(jù)量突增一下子把數(shù)據(jù)庫的 CPU 打滿結(jié)果線上所有寫操作超時(shí)。運(yùn)營只是點(diǎn)了導(dǎo)出的按鈕整個(gè)業(yè)務(wù)就掛了。后來我們做的改造很簡單把報(bào)表查詢拆成多次單表查詢在應(yīng)用層做計(jì)算數(shù)據(jù)庫負(fù)載立刻降了下來雖然運(yùn)營導(dǎo)出慢了幾秒但線上核心鏈路穩(wěn)了。對于業(yè)務(wù)系統(tǒng)來說可用性永遠(yuǎn)高于局部性能。濫用 join 等于把多個(gè)服務(wù)的可用性都押在一臺(tái)數(shù)據(jù)庫上這本身就是一個(gè)風(fēng)險(xiǎn)集中的方案。與其在數(shù)據(jù)庫里做復(fù)雜計(jì)算不如把計(jì)算放到應(yīng)用層讓數(shù)據(jù)庫專注做它最擅長的事情單表的增刪改查。2.3 一致性與可維護(hù)性成本很多人以為 join 能保證數(shù)據(jù)一致性因?yàn)樗谝粋€(gè)事務(wù)里同時(shí)讀了多張表。但這里有個(gè)誤解join 只是讀操作它不能保證參與 join 的其他表的數(shù)據(jù)是“最新”的也管不了“寫”的一致性。如果業(yè)務(wù)需要同時(shí)更新多張表你仍然要用事務(wù)或者分布式事務(wù)去解決而不是靠 join。從可維護(hù)性角度看多表 join 的 SQL 會(huì)變得越來越難改。表結(jié)構(gòu)一變索引一變關(guān)聯(lián)關(guān)系一變你可能要翻出十幾個(gè)文件里幾十條 SQL 來改。而且 join 查詢很難做單元測試你沒法輕易地在測試環(huán)境構(gòu)造多張表的數(shù)據(jù)關(guān)系。相比之下拆成多個(gè)單表查詢后每個(gè)查詢邏輯清晰mock 也容易出問題也更容易定位。還有一點(diǎn)join 經(jīng)常會(huì)把不該暴露給調(diào)用方的數(shù)據(jù)帶出來。比如一個(gè)訂單查詢只想要訂單號(hào)和時(shí)間但因?yàn)?join 了用戶表SQL 里不小心多選了用戶的手機(jī)號(hào)、地址等敏感字段一旦接口輸出到前端隱私風(fēng)險(xiǎn)跟著就來了。拆成獨(dú)立的查詢至少每個(gè)查詢的字段邊界是可控的。3. 什么場景下 Join 仍然是最優(yōu)解3.1 適合用 Join 的三個(gè)條件我不是說 join 一定不能用相反在很多場景下 join 仍然是最高效的方案。我總結(jié)下來至少滿足這三個(gè)條件時(shí)你可以放心用條件說明驅(qū)動(dòng)表數(shù)據(jù)量可控比如主表只有幾千到幾萬行而不是幾百萬行關(guān)聯(lián)字段有合適索引被驅(qū)動(dòng)表的關(guān)聯(lián)列有唯一索引或普通索引且區(qū)分度高并發(fā)量不高允許查詢占據(jù)一定數(shù)據(jù)庫資源不會(huì)打爆連接池最典型的就是后臺(tái)管理系統(tǒng)的列表查詢或者報(bào)表系統(tǒng)里的明細(xì)查詢。比如查詢訂單列表關(guān)聯(lián)一張只有幾百行的配送區(qū)域表這種 join 完全可以接受。又比如查詢商品分類時(shí)關(guān)聯(lián)一張分類表性能也不會(huì)有問題。因?yàn)轵?qū)動(dòng)表小、索引齊全MySQL 的優(yōu)化器能很快完成匹配。還有一種適合 join 的場景是你確實(shí)需要一次性讀取強(qiáng)關(guān)聯(lián)的數(shù)據(jù)而且這些數(shù)據(jù)不會(huì)單獨(dú)被復(fù)用。比如訂單詳情頁同時(shí)需要訂單基本信息、訂單商品明細(xì)、訂單支付結(jié)果這三張表本身就是同一個(gè)聚合根的組成部分join 一次拿回來是合理的。這時(shí)候拆成三次查詢反而增加了網(wǎng)絡(luò)往返和代碼復(fù)雜度join 反而更干凈。3.2 同樣一條 SQL換個(gè)寫法差 10 倍我見過不少“談 join 色變”的團(tuán)隊(duì)把所有 join 一律禁止結(jié)果代碼里出現(xiàn)一百個(gè) N1 查詢。這種因噎廢食的做法也不對。真正重要的是判斷 join 的數(shù)據(jù)量級(jí)和索引情況。舉個(gè)例子有一個(gè)商品評論接口需要展示評論內(nèi)容、評論用戶昵稱、商品標(biāo)題。評論表 500 萬行用戶表 20 萬行商品表 10 萬行。我們當(dāng)時(shí)的寫法是 join 兩個(gè)表然后只查當(dāng)前頁的 20 條評論。SQL 如下SELECT c.id, c.content, u.nickname, p.title FROM comments c JOIN users u ON c.user_id u.id JOIN products p ON c.product_id p.id WHERE c.product_id 1001 ORDER BY c.created_at DESC LIMIT 20由于 comments 表上有 product_id 的索引驅(qū)動(dòng)表會(huì)被過濾到只有幾十條users 和 products 都走主鍵索引整個(gè)查詢執(zhí)行時(shí)間穩(wěn)定在 20ms 以內(nèi)。如果你不看表結(jié)構(gòu)盲目要求拆成三次查詢反而多出兩次網(wǎng)絡(luò)往返接口變慢且代碼更復(fù)雜。所以“join 到底能不能用”不是一個(gè)簡單的 yes no而是要看驅(qū)動(dòng)表篩選后的結(jié)果集有多大。凡是驅(qū)動(dòng)表能通過 where 條件縮小到很小的集合并且關(guān)聯(lián)表都有索引join 就是高效且正確的選擇。怕就怕那種沒有篩選條件、上來就大表 join 大表的寫法那種才是真正的濫用。4. Golang 應(yīng)用里的 Join 替代方案附代碼4.1 明確數(shù)據(jù)歸屬Repository 層只查本模塊在 Golang 的業(yè)務(wù)系統(tǒng)里我推薦的做法是先用 Repository 層把數(shù)據(jù)邊界劃清楚。訂單的 Repository 只查訂單表用戶的 Repository 只查用戶表商品的 Repository 只查商品表。每個(gè) Repository 的方法負(fù)責(zé)一個(gè)簡單的單表查詢返回結(jié)構(gòu)體或切片。這樣的好處是每個(gè)查詢都可以獨(dú)立做緩存獨(dú)立測試獨(dú)立優(yōu)化。比如有一個(gè)訂單列表的用例需要返回訂單信息和買家昵稱。先定義兩個(gè) Repositorytype OrderRepo struct { db *sql.DB } type UserRepo struct { db *sql.DB } func (r *OrderRepo) ListByStatus(ctx context.Context, status int, limit, offset int) ([]Order, error) { rows, err : r.db.QueryContext(ctx, SELECT id, user_id, product_id, amount, status FROM orders WHERE status ? ORDER BY created_at DESC LIMIT ? OFFSET ?, status, limit, offset) // ... } func (r *UserRepo) BatchGetByIDs(ctx context.Context, ids []int64) (map[int64]User, error) { // 使用 IN 查詢批量獲取 }你可能會(huì)問這樣豈不是每個(gè)接口都要寫好幾遍查詢邏輯其實(shí)不會(huì)。批量查詢是高度復(fù)用的方法比如BatchGetByIDs可以被訂單列表、評論列表、售后列表同時(shí)使用。維護(hù)一份查詢邏輯比在每個(gè)接口里寫一段多表 join 要安全得多。4.2 多次查詢 內(nèi)存聚合的標(biāo)準(zhǔn)姿勢拆成多次查詢后最關(guān)鍵的點(diǎn)是在應(yīng)用層做聚合而不是循環(huán)里逐條查詢。很多人拆到一半又寫出了 N1 查詢性能比 join 還差。正確的姿勢是先查主數(shù)據(jù)收集關(guān)聯(lián) ID再批量查關(guān)聯(lián)數(shù)據(jù)最后在內(nèi)存里組裝。我在項(xiàng)目里的標(biāo)準(zhǔn)寫法差不多這樣func GetOrderDetails(ctx context.Context, status int, limit, offset int) ([]OrderDetail, error) { orders, err : orderRepo.ListByStatus(ctx, status, limit, offset) if err ! nil { return nil, err } userIDs : make([]int64, 0, len(orders)) productIDs : make([]int64, 0, len(orders)) userIDSet : make(map[int64]struct{}) productIDSet : make(map[int64]struct{}) for _, o : range orders { if _, ok : userIDSet[o.UserID]; !ok { userIDSet[o.UserID] struct{}{} userIDs append(userIDs, o.UserID) } if _, ok : productIDSet[o.ProductID]; !ok { productIDSet[o.ProductID] struct{}{} productIDs append(productIDs, o.ProductID) } } userMap, err : userRepo.BatchGetByIDs(ctx, userIDs) if err ! nil { return nil, err } productMap, err : productRepo.BatchGetByIDs(ctx, productIDs) if err ! nil { return nil, err } details : make([]OrderDetail, 0, len(orders)) for _, o : range orders { details append(details, OrderDetail{ Order: o, userName: userMap[o.UserID].Name, product: productMap[o.ProductID].Title, }) } return details, nil }這段代碼的邏輯是先查訂單列表再把所有 user_id 和 product_id 收集成兩個(gè)去重后的切片分別批量查詢最后用 map 做關(guān)聯(lián)。整個(gè)過程只查三張表每張表都是簡單查詢就算訂單表有 500 萬行只要 where 條件能把結(jié)果集過濾到幾十條性能就是可控的。這里有幾個(gè)細(xì)節(jié)值得注意。批量查詢的IN條件如果太長MySQL 可能會(huì)因?yàn)樗饕鶖?shù)估算不準(zhǔn)而走全表掃描建議分批查詢比如每批 500 個(gè) ID。同時(shí)去重很重要否則一個(gè)用戶有 200 個(gè)訂單你就把同一個(gè)用戶查了 200 遍雖然拉出來是同一個(gè)用戶但無謂地增加了查詢的壓力。4.3 使用 sqlc/GORM 時(shí)怎么避免隱式 JoinGolang 生態(tài)里很多人用 GORM 或 sqlc 操作數(shù)據(jù)庫。GORM 的Preload方法其實(shí)已經(jīng)幫你把 join 拆成了多條查詢默認(rèn)實(shí)現(xiàn)是先查主表再根據(jù)主表的 ID 去查關(guān)聯(lián)表本質(zhì)就是我們上面說的批量查詢加內(nèi)存聚合。但 GORM 也有坑比如預(yù)加載嵌套層級(jí)太深或者循環(huán)里使用Association方法照樣會(huì)產(chǎn)生 N1 查詢。如果你用 sqlc它本身不關(guān)心你是 join 還是分次查詢它只是把你寫的 SQL 轉(zhuǎn)換成 Go 代碼。這種情況下我建議你在 SQL 層面就要刻意控制 join 的使用別把需要跨表查詢的邏輯寫進(jìn)同一條 SQL 里。sqlc 生成的方法越簡單后續(xù)拆分和優(yōu)化就越容易。還有一個(gè)容易忽略的點(diǎn)事務(wù)邊界。如果你拆成多次查詢但要保證這些數(shù)據(jù)的強(qiáng)一致不能簡單地在應(yīng)用層分開查因?yàn)榉珠_查肯定有中間狀態(tài)。業(yè)務(wù)系統(tǒng)一般不建議追求強(qiáng)一致而是通過最終一致性來解決。比如訂單支付后把支付結(jié)果寫入訂單表同時(shí)異步推送商品銷量更新只要最終商品銷量是對的就不需要在一個(gè)事務(wù)里同時(shí)鎖住訂單表和商品表。這個(gè)思想比任何框架選型都重要。5. Python 應(yīng)用里的 Join 替代方案附代碼5.1 ORM 的 select_related 和 prefetch_related 別亂用Python 生態(tài)里Django 和 SQLAlchemy 是主流 ORM它們提供了非常方便的關(guān)聯(lián)加載方法但也正是因?yàn)榉奖愫芏嗳税阉鼈冇贸闪诵阅軞⑹?。Django 的select_related是通過 SQL join 實(shí)現(xiàn)的適合一對一和一對多外鍵關(guān)系比如order.user。它會(huì)一次性把關(guān)聯(lián)的表 join 出來如果你只查少數(shù)幾條主記錄效果很好。但如果你查了一個(gè) 10000 條記錄的 querysetselect_related會(huì)把所有關(guān)聯(lián)表也 join 進(jìn)來返回大量冗余列網(wǎng)絡(luò)和內(nèi)存都會(huì)爆炸。prefetch_related則是先查主表再查詢關(guān)聯(lián)表在 Python 內(nèi)存里完成關(guān)聯(lián)這個(gè)邏輯其實(shí)和我們在 Golang 里手動(dòng)做的聚合是一致的。但它的缺陷在于每次prefetch_related都會(huì)額外執(zhí)行幾條 SQL如果預(yù)加載層級(jí)很多比如prefetch_related(items__product__category)查詢數(shù)量會(huì)成倍增加。所以我的建議是Django ORM 只適合簡單的兩級(jí)關(guān)聯(lián)超過兩級(jí)就手動(dòng)寫bulk查詢不要迷信 ORM 的“魔法”。我見過一個(gè)后臺(tái)列表接口Django ORM 自動(dòng)預(yù)加載了訂單、商品、用戶、店鋪四層關(guān)系結(jié)果接口讀取了十幾張表的數(shù)據(jù)頁面加載要 8 秒。改造后用批量查詢加內(nèi)存字典合并接口降到 500ms。5.2 用批量查詢和內(nèi)存聚合替代 Join在 Python 業(yè)務(wù)代碼里我推薦先查主表再批量獲取關(guān)聯(lián)表數(shù)據(jù)最后構(gòu)建一個(gè)字典來映射。這和 Golang 的做法完全一致只是語法更簡潔。orders list(Order.objects.filter(status1)[:20]) user_ids list({o.user_id for o in orders}) product_ids list({o.product_id for o in orders}) users User.objects.filter(id__inuser_ids) user_map {u.id: u for u in users} products Product.objects.filter(id__inproduct_ids) product_map {p.id: p for p in products} result [] for order in orders: result.append({ order_id: order.id, user_name: user_map[order.user_id].name, product_title: product_map[order.product_id].title, })這個(gè)寫法保證了查詢次數(shù)固定是 3 次不會(huì)隨著訂單條數(shù)增長而增長。更重要的是這三條查詢都能利用數(shù)據(jù)庫索引單表查詢的性能非常好預(yù)測。如果以后訂單表拆分到獨(dú)立的庫你只需要修改Order的 Model 指向新庫其他代碼完全不用動(dòng)。對于那些必須實(shí)時(shí)展示的接口還可以把最終結(jié)果緩存到 Redis 里key 比如order:list:status:1:page:1過期時(shí)間設(shè) 60 秒。這樣即使底層查詢再慢用戶也不會(huì)直接感知到數(shù)據(jù)庫壓力。當(dāng)然緩存失效策略要設(shè)計(jì)好否則會(huì)出現(xiàn)數(shù)據(jù)延遲這個(gè)在業(yè)務(wù)上能不能接受要提前評估。5.3 asyncio 并發(fā)批量查詢需要注意的坑Python 3.8 以后async/await越來越普及很多人喜歡用 asyncio.gather 同時(shí)發(fā)多個(gè)數(shù)據(jù)庫查詢希望用并發(fā)替代 join。思路是對的但坑也很多。比如同時(shí)發(fā)幾十個(gè)查詢每個(gè)查詢都要占用一個(gè)數(shù)據(jù)庫連接如果連接池太小反而會(huì)因?yàn)榕抨?duì)導(dǎo)致請求更慢。我建議你只在“批量獲取多個(gè)關(guān)聯(lián) ID 的明細(xì)”這一步使用并發(fā)并且限制并發(fā)數(shù)。用asyncio.Semaphore控制同時(shí)執(zhí)行的查詢數(shù)量避免瞬間把連接池打滿。另外數(shù)據(jù)庫驅(qū)動(dòng)要選支持異步的版本Django 可以配async模式但底層數(shù)據(jù)庫連接依然是同步的不配合連接池效果并不好。還有一個(gè)更容易被忽略的點(diǎn)如果你用了asyncio.gather去并發(fā)查詢但其中一個(gè)查詢失敗其他查詢可能已經(jīng)執(zhí)行了這樣會(huì)留下不完整的狀態(tài)。最好是在全部查詢成功后再更新數(shù)據(jù)或者通過事務(wù)把幾個(gè)查詢包起來。但對于只讀查詢即使有一個(gè)失敗重試整個(gè)請求并不會(huì)造成數(shù)據(jù)問題所以也不必過于緊張。6. 工程落地拆 Join 的決策流程與補(bǔ)償機(jī)制6.1 拆 Join 的通用決策流程面對一條復(fù)雜的多表 join我建議按下面的步驟判斷要不要拆先看查詢條件能不能把驅(qū)動(dòng)表的數(shù)據(jù)量壓縮到百條以內(nèi)。如果能join 大概率沒問題。再看關(guān)聯(lián)字段有沒有索引。沒有索引哪怕驅(qū)動(dòng)表數(shù)據(jù)量小也可能拿到一條慢查詢。然后看這個(gè)查詢在不在核心鏈路。如果用戶每次下單都會(huì)命中它就必須嚴(yán)格控制響應(yīng)時(shí)間。如果查詢的表分屬不同業(yè)務(wù)模塊優(yōu)先拆開。等將來分庫分表你會(huì)感謝這個(gè)決定。如果拆開以后需要多次查詢才能搞定數(shù)據(jù)聚合就設(shè)計(jì)好批量查詢和緩存避免出現(xiàn) N1。上線前用 EXPLAIN 和執(zhí)行計(jì)劃驗(yàn)證別憑感覺。這個(gè)流程是我在實(shí)際項(xiàng)目中反復(fù)使用的。拆 join 不是目的目的是讓數(shù)據(jù)訪問模式可控。之前我們拆過一個(gè)用戶維度的匯總報(bào)表原來一條 SQL 同時(shí) join 了訂單表和退款表跑了 20 秒。拆開后先查詢訂單表再用退款表批量查詢應(yīng)用層做合并報(bào)表時(shí)間降到 2 秒。同樣是拿到結(jié)果數(shù)據(jù)庫的壓力卻小了非常多。6.2 數(shù)據(jù)不一致時(shí)的補(bǔ)償方案把 join 拆成多次查詢以后最讓人擔(dān)心的就是數(shù)據(jù)一致性。比如你先查了訂單表再查用戶表結(jié)果用戶在這中間改了昵稱你返回的還是舊昵稱。這在大部分業(yè)務(wù)系統(tǒng)里是可以接受的畢竟用戶昵稱不是強(qiáng)一致數(shù)據(jù)。真正需要在意的是訂單金額、庫存這類數(shù)據(jù)不能有偏差。我的經(jīng)驗(yàn)是把強(qiáng)一致的數(shù)據(jù)放在同一張表或同一個(gè)聚合里用數(shù)據(jù)庫事務(wù)保證把弱一致的數(shù)據(jù)拆開通過消息隊(duì)列、定時(shí)任務(wù)或者版本號(hào)做最終一致。比如下單扣庫存訂單和庫存是強(qiáng)相關(guān)的必須在一個(gè)事務(wù)里處理而訂單和用戶昵稱則沒關(guān)系拆開完全不影響業(yè)務(wù)正確性。有些團(tuán)隊(duì)會(huì)用本地消息表來保證一致性應(yīng)用先把業(yè)務(wù)操作寫入業(yè)務(wù)表同時(shí)寫一條“待處理消息”到本地消息表然后異步任務(wù)掃描消息表把數(shù)據(jù)同步到其他模塊。這種方式簡單可靠不需要引入重量級(jí)中間件也能滿足大部分場景。等系統(tǒng)規(guī)模大到需要引入消息隊(duì)列時(shí)再平滑遷移即可。6.3 上線前必須做的三件事別等線上慢查詢告警了才開始調(diào)優(yōu)。每次涉及 join 變更我強(qiáng)烈建議上線前做三件事開啟慢查詢?nèi)罩居?EXPLAIN 分析執(zhí)行計(jì)劃做一次最簡單的壓測。慢查詢?nèi)罩灸芨嬖V你哪些 SQL 超過了閾值比如long_query_time1就是 1 秒以上記錄。通過日志找到最耗時(shí)的查詢再用EXPLAIN看它的執(zhí)行計(jì)劃重點(diǎn)關(guān)注 type 字段如果從ALL全表掃描變成ref或eq_ref說明索引起了作用如果出現(xiàn)Using temporary或Using filesort意味著 MySQL 在處理排序或臨時(shí)表需要進(jìn)一步優(yōu)化。壓測也很重要。不需要復(fù)雜的工具用一個(gè)簡單的腳本模擬 100 個(gè)并發(fā)用戶調(diào)用接口觀察數(shù)據(jù)庫連接數(shù)和響應(yīng)時(shí)間。如果你拆成多次查詢后數(shù)據(jù)庫連接數(shù)依然穩(wěn)定說明架構(gòu)是健康的如果連接數(shù)飆升那就要考慮加連接池或減少查詢次數(shù)了。上線前這些工作花不了太多時(shí)間卻能避免線上很多尷尬。7. 實(shí)戰(zhàn)排查慢 Join 的處理技巧與踩坑記錄7.1 一條慢 Join 的排查實(shí)錄之前我接手過一個(gè)電商后臺(tái)的訂單查詢接口用戶反饋響應(yīng)越來越慢。我打開慢查詢?nèi)罩景l(fā)現(xiàn)一條 SQL 要跑 4 秒SELECT o.id, o.order_no, u.phone, p.title FROM orders o LEFT JOIN users u ON o.user_id u.id LEFT JOIN products p ON o.product_id p.id ORDER BY o.created_at DESC LIMIT 20;第一眼看上去很合理只取 20 條還有LIMIT。真正的問題在于ORDER BY o.created_at DESC在orders表上沒有合適的索引MySQL 只能先把所有滿足條件的行排序再取 20 條。即使訂單只有 50 萬行這個(gè)排序也很消耗性能。我讓開發(fā)同學(xué)給orders(created_at, id)加了一個(gè)聯(lián)合索引查詢立刻降到 80ms。加索引之后EXPLAIN的 type 從ALL變成了rangeExtra 里也不再出現(xiàn)Using filesort。這就是一個(gè)典型的“join 不背鍋索引沒到位才背鍋”的例子。7.2 容易踩的坑LEFT JOIN 與 INNER JOIN 結(jié)果不一致有不少同學(xué)分不清LEFT JOIN和INNER JOIN。比如查詢所有訂單然后 LEFT JOIN 用戶表想顯示“即使是已注銷的用戶也要顯示訂單”。這個(gè)思路沒問題但如果你在 WHERE 里加了u.status 1那么 LEFT JOIN 就退化成 INNER JOIN 了已注銷用戶的訂單就消失了。SELECT o.id, u.name FROM orders o LEFT JOIN users u ON o.user_id u.id WHERE u.status 1這個(gè)寫法是錯(cuò)誤的。如果想保留訂單且過濾用戶狀態(tài)應(yīng)該把條件放到ON子句里SELECT o.id, u.name FROM orders o LEFT JOIN users u ON o.user_id u.id AND u.status 1類似的坑還出現(xiàn)在多表 join 后做分頁統(tǒng)計(jì)時(shí)。兩表關(guān)聯(lián)會(huì)產(chǎn)生笛卡爾積如果一對多關(guān)系導(dǎo)致訂單行數(shù)被放大再去COUNT(*)就會(huì)得到錯(cuò)誤數(shù)量。這種問題用 join 很難直觀發(fā)現(xiàn)等你查出來的數(shù)據(jù)對不上賬再去排查就非常麻煩了。拆成多次查詢后統(tǒng)計(jì)邏輯是各自獨(dú)立的反而更容易看清楚。7.3 我的幾個(gè)實(shí)操心得我在項(xiàng)目里處理 join 問題已經(jīng)很多年了最后分享幾個(gè)個(gè)人體會(huì)。第一如果一段查詢邏輯里出現(xiàn)了三個(gè)以上的 join我基本會(huì)停下來重新審視是不是數(shù)據(jù)建模有問題而不是急著去調(diào)優(yōu) SQL。第二拆查詢之前先把“需要的數(shù)據(jù)范圍”想清楚不要一次把整張表的所有字段都撈出來減少網(wǎng)絡(luò)傳輸量和應(yīng)用內(nèi)存占用。第三無論用 Golang 還是 Python內(nèi)存聚合的代碼一定要寫在 Service 層不要散落在 Handler 或視圖函數(shù)里否則后續(xù)維護(hù)會(huì)很痛苦。還有一個(gè)心得是如果業(yè)務(wù)模塊之間確實(shí)需要頻繁地聯(lián)表查詢那說明它們在業(yè)務(wù)上可能本就不該分得太開。這時(shí)候更值得考慮的是調(diào)整數(shù)據(jù)模型比如把經(jīng)常一起查詢的字段冗余到同一張表里而不是繼續(xù)在查詢層做文章。畢竟解決一個(gè)問題最好的方式是從源頭避免它而不是等它變成事故再救火。做技術(shù)選型和 SQL 設(shè)計(jì)時(shí)把 join 當(dāng)成一把錘子別把所有問題都當(dāng)成釘子?？刂坪脭?shù)據(jù)訪問邊界關(guān)注數(shù)據(jù)庫的執(zhí)行代價(jià)結(jié)合應(yīng)用層的批量查詢和緩存整個(gè)業(yè)務(wù)系統(tǒng)才能睡得安穩(wěn)。 MySQL Join 性能優(yōu)化：何時(shí)使用、何時(shí)拆分，附 Golang 與 Python 實(shí)戰(zhàn)
我在做技術(shù)方案評審的時(shí)候最怕聽到的一句話就是“先 join 查出來再說后面不行再拆?！闭f這話的人往往沒想過一個(gè)看似簡單的 join在業(yè)務(wù)系統(tǒng)里跑起來之后會(huì)成為慢查詢、連接池耗盡、甚至分庫分表推倒重來的起點(diǎn)。MySQL 的 join 不是不能用而是要看清代價(jià)。今天這篇我把自己在 Golang 和 Python 業(yè)務(wù)項(xiàng)目里處理 join 的經(jīng)驗(yàn)整理出來包括什么時(shí)候該用、什么時(shí)候不該用、拆開之后怎么寫以及踩過的坑。1. 別急著寫 Join先看清 MySQL 的執(zhí)行代價(jià)1.1 一次 Join 背后的執(zhí)行過程MySQL 里最常見的 join 執(zhí)行方式是 Nested Loop Join簡單說就是拿一張表當(dāng)外循環(huán)再拿另一張表當(dāng)內(nèi)循環(huán)一行一行去匹配。比如這條查詢SELECT o.id, u.name, p.title FROM orders o JOIN users u ON o.user_id u.id JOIN products p ON o.product_id p.id WHERE o.status 1MySQL 大概率會(huì)把 orders 當(dāng)成驅(qū)動(dòng)表然后拿著 o.user_id 去 users 表的主鍵索引里逐行查找再拿著 o.product_id 去 products 表里逐行查找。如果兩張表的關(guān)聯(lián)字段都有索引這叫 Index Nested-Loop Join性能尚可。如果其中一張表沒有索引MySQL 就不得不把整張表掃一遍這叫 Simple Nested-Loop Join數(shù)據(jù)量一大基本就是災(zāi)難。這里可以有個(gè)生活化的類比你手上有 10000 張訂單每張訂單要找到對應(yīng)的用戶姓名。如果用戶表有一個(gè)按 ID 排好的電話簿你每次都能直接翻到那一頁速度很快。如果用戶表沒有整理過你每查一個(gè)訂單都要從頭到尾翻一遍電話簿10000 單就是 10000 次全表掃描。所以很多人問“為什么我的 join 這么慢”答案往往不是 join 本身慢而是關(guān)聯(lián)字段上根本沒有索引或者驅(qū)動(dòng)表選錯(cuò)了。到了 MySQL 8.0優(yōu)化器引入了 Hash Join專門處理等值關(guān)聯(lián)且沒有索引的情況。但它也有代價(jià)會(huì)把其中一張表的數(shù)據(jù)加載到內(nèi)存里建哈希表內(nèi)存不夠時(shí)就落盤慢查詢照樣慢。很多人以為升級(jí)到 8.0 就萬事大吉實(shí)際上 Hash Join 只能緩解一部分問題如果你的業(yè)務(wù)表都是千萬級(jí)數(shù)據(jù)join 的代價(jià)依然很可觀。1.2 業(yè)務(wù)系統(tǒng)里的 Join 為什么會(huì)越來越慢很多業(yè)務(wù)系統(tǒng)剛開始用 join 時(shí)很快因?yàn)閿?shù)據(jù)量小。訂單表幾千行用戶表幾百行隨便 join 都是毫秒級(jí)?？上到y(tǒng)跑了半年一年后訂單表漲到幾百萬甚至上千萬用戶表和商品表也膨脹到幾十萬行原來那個(gè)“看著很合理”的 join 就開始露餡了。有幾個(gè)原因疊加在一起會(huì)讓 join 越來越慢第一關(guān)聯(lián)字段的索引因?yàn)閿?shù)據(jù)分布變化而失效。比如你關(guān)聯(lián)的是邏輯刪除字段、狀態(tài)字段這種字段上建索引區(qū)分度太低優(yōu)化器寧愿全表掃也不走索引。第二join 后的結(jié)果集比單表大很多再加上排序、分組、分頁可能要把中間結(jié)果放到臨時(shí)表里消耗大量內(nèi)存和磁盤 IO。第三一旦涉及多表查詢占用的行鎖和事務(wù)時(shí)間也變長在高并發(fā)下很容易拖垮其他簡單查詢。舉一個(gè)我實(shí)際評審過的例子某后臺(tái)訂單導(dǎo)出功能SQL 里 join 了 orders、users、store、payments 四張表還要按用戶手機(jī)號(hào)過濾、按下單時(shí)間排序。上線初期數(shù)據(jù)量 20 萬時(shí)接口響應(yīng) 300ms。到了 300 萬訂單時(shí)響應(yīng)直接變成 6 秒最后把整個(gè)訂單庫的連接池打滿連帶著線上下單都卡了。這種事故幾乎每天都在各種公司的技術(shù)團(tuán)隊(duì)里發(fā)生問題不在 SQL 寫錯(cuò)而在業(yè)務(wù)系統(tǒng)里濫用 join把數(shù)據(jù)庫當(dāng)成了計(jì)算引擎。2. 業(yè)務(wù)系統(tǒng)里濫用 Join 的隱藏成本2.1 表結(jié)構(gòu)耦合導(dǎo)致后續(xù)拆分寸步難行濫用 join 的代價(jià)不只是性能。還有一個(gè)特別隱蔽的問題它在代碼層面把本來可以獨(dú)立的業(yè)務(wù)模塊死死綁在一起。比如用戶服務(wù)、訂單服務(wù)、商品服務(wù)本來應(yīng)該各自維護(hù)自己的數(shù)據(jù)結(jié)果你一條 join 直接把三張表拉在一起查相當(dāng)于在數(shù)據(jù)庫層面提前做了一個(gè)“分布式查詢”但系統(tǒng)架構(gòu)根本沒有準(zhǔn)備好。等你想把訂單服務(wù)拆出來獨(dú)立部署把用戶表挪到另一個(gè)庫時(shí)原來的 SQL 全部作廢?？鐜?join 在 MySQL 原生實(shí)現(xiàn)里是不支持的雖然 FEDERATED 引擎和某些中間件能模擬但性能和一致性都很差。那時(shí)候你只能哭著把所有 join 拆成多次查詢?nèi)缓笮扪a(bǔ)各種緩存和數(shù)據(jù)不一致的坑。所以我在設(shè)計(jì)業(yè)務(wù)系統(tǒng)時(shí)有一個(gè)原則看一條 SQL 就知道這個(gè)模塊的邊界在哪里。如果訂單查詢里 join 了用戶表說明訂單模塊還沒想清楚自己的數(shù)據(jù)邊界。正確做法是把用戶 ID 存到訂單表里需要用戶信息時(shí)通過用戶服務(wù)接口批量獲取而不是直接 join 用戶表。2.2 可用性和擴(kuò)展性受損業(yè)務(wù)系統(tǒng)最怕的不是某個(gè)接口慢而是慢查詢把整個(gè)數(shù)據(jù)庫實(shí)例拖垮。Join 越多數(shù)據(jù)庫 CPU、內(nèi)存、IO 的壓力越大。應(yīng)用服務(wù)可以橫向加機(jī)器數(shù)據(jù)庫卻很難簡單地通過加機(jī)器解決讀壓力尤其是大量 join 疊加后單個(gè)慢查詢就能把連接池吃完其他正常查詢?nèi)颗抨?duì)。我見過一個(gè)比較典型的場景運(yùn)營后臺(tái)一個(gè)多表 join 的大報(bào)表因?yàn)槟程鞌?shù)據(jù)量突增一下子把數(shù)據(jù)庫的 CPU 打滿結(jié)果線上所有寫操作超時(shí)。運(yùn)營只是點(diǎn)了導(dǎo)出的按鈕整個(gè)業(yè)務(wù)就掛了。后來我們做的改造很簡單把報(bào)表查詢拆成多次單表查詢在應(yīng)用層做計(jì)算數(shù)據(jù)庫負(fù)載立刻降了下來雖然運(yùn)營導(dǎo)出慢了幾秒但線上核心鏈路穩(wěn)了。對于業(yè)務(wù)系統(tǒng)來說可用性永遠(yuǎn)高于局部性能。濫用 join 等于把多個(gè)服務(wù)的可用性都押在一臺(tái)數(shù)據(jù)庫上這本身就是一個(gè)風(fēng)險(xiǎn)集中的方案。與其在數(shù)據(jù)庫里做復(fù)雜計(jì)算不如把計(jì)算放到應(yīng)用層讓數(shù)據(jù)庫專注做它最擅長的事情單表的增刪改查。2.3 一致性與可維護(hù)性成本很多人以為 join 能保證數(shù)據(jù)一致性因?yàn)樗谝粋€(gè)事務(wù)里同時(shí)讀了多張表。但這里有個(gè)誤解join 只是讀操作它不能保證參與 join 的其他表的數(shù)據(jù)是“最新”的也管不了“寫”的一致性。如果業(yè)務(wù)需要同時(shí)更新多張表你仍然要用事務(wù)或者分布式事務(wù)去解決而不是靠 join。從可維護(hù)性角度看多表 join 的 SQL 會(huì)變得越來越難改。表結(jié)構(gòu)一變索引一變關(guān)聯(lián)關(guān)系一變你可能要翻出十幾個(gè)文件里幾十條 SQL 來改。而且 join 查詢很難做單元測試你沒法輕易地在測試環(huán)境構(gòu)造多張表的數(shù)據(jù)關(guān)系。相比之下拆成多個(gè)單表查詢后每個(gè)查詢邏輯清晰mock 也容易出問題也更容易定位。還有一點(diǎn)join 經(jīng)常會(huì)把不該暴露給調(diào)用方的數(shù)據(jù)帶出來。比如一個(gè)訂單查詢只想要訂單號(hào)和時(shí)間但因?yàn)?join 了用戶表SQL 里不小心多選了用戶的手機(jī)號(hào)、地址等敏感字段一旦接口輸出到前端隱私風(fēng)險(xiǎn)跟著就來了。拆成獨(dú)立的查詢至少每個(gè)查詢的字段邊界是可控的。3. 什么場景下 Join 仍然是最優(yōu)解3.1 適合用 Join 的三個(gè)條件我不是說 join 一定不能用相反在很多場景下 join 仍然是最高效的方案。我總結(jié)下來至少滿足這三個(gè)條件時(shí)你可以放心用條件說明驅(qū)動(dòng)表數(shù)據(jù)量可控比如主表只有幾千到幾萬行而不是幾百萬行關(guān)聯(lián)字段有合適索引被驅(qū)動(dòng)表的關(guān)聯(lián)列有唯一索引或普通索引且區(qū)分度高并發(fā)量不高允許查詢占據(jù)一定數(shù)據(jù)庫資源不會(huì)打爆連接池最典型的就是后臺(tái)管理系統(tǒng)的列表查詢或者報(bào)表系統(tǒng)里的明細(xì)查詢。比如查詢訂單列表關(guān)聯(lián)一張只有幾百行的配送區(qū)域表這種 join 完全可以接受。又比如查詢商品分類時(shí)關(guān)聯(lián)一張分類表性能也不會(huì)有問題。因?yàn)轵?qū)動(dòng)表小、索引齊全MySQL 的優(yōu)化器能很快完成匹配。還有一種適合 join 的場景是你確實(shí)需要一次性讀取強(qiáng)關(guān)聯(lián)的數(shù)據(jù)而且這些數(shù)據(jù)不會(huì)單獨(dú)被復(fù)用。比如訂單詳情頁同時(shí)需要訂單基本信息、訂單商品明細(xì)、訂單支付結(jié)果這三張表本身就是同一個(gè)聚合根的組成部分join 一次拿回來是合理的。這時(shí)候拆成三次查詢反而增加了網(wǎng)絡(luò)往返和代碼復(fù)雜度join 反而更干凈。3.2 同樣一條 SQL換個(gè)寫法差 10 倍我見過不少“談 join 色變”的團(tuán)隊(duì)把所有 join 一律禁止結(jié)果代碼里出現(xiàn)一百個(gè) N1 查詢。這種因噎廢食的做法也不對。真正重要的是判斷 join 的數(shù)據(jù)量級(jí)和索引情況。舉個(gè)例子有一個(gè)商品評論接口需要展示評論內(nèi)容、評論用戶昵稱、商品標(biāo)題。評論表 500 萬行用戶表 20 萬行商品表 10 萬行。我們當(dāng)時(shí)的寫法是 join 兩個(gè)表然后只查當(dāng)前頁的 20 條評論。SQL 如下SELECT c.id, c.content, u.nickname, p.title FROM comments c JOIN users u ON c.user_id u.id JOIN products p ON c.product_id p.id WHERE c.product_id 1001 ORDER BY c.created_at DESC LIMIT 20由于 comments 表上有 product_id 的索引驅(qū)動(dòng)表會(huì)被過濾到只有幾十條users 和 products 都走主鍵索引整個(gè)查詢執(zhí)行時(shí)間穩(wěn)定在 20ms 以內(nèi)。如果你不看表結(jié)構(gòu)盲目要求拆成三次查詢反而多出兩次網(wǎng)絡(luò)往返接口變慢且代碼更復(fù)雜。所以“join 到底能不能用”不是一個(gè)簡單的 yes no而是要看驅(qū)動(dòng)表篩選后的結(jié)果集有多大。凡是驅(qū)動(dòng)表能通過 where 條件縮小到很小的集合并且關(guān)聯(lián)表都有索引join 就是高效且正確的選擇。怕就怕那種沒有篩選條件、上來就大表 join 大表的寫法那種才是真正的濫用。4. Golang 應(yīng)用里的 Join 替代方案附代碼4.1 明確數(shù)據(jù)歸屬Repository 層只查本模塊在 Golang 的業(yè)務(wù)系統(tǒng)里我推薦的做法是先用 Repository 層把數(shù)據(jù)邊界劃清楚。訂單的 Repository 只查訂單表用戶的 Repository 只查用戶表商品的 Repository 只查商品表。每個(gè) Repository 的方法負(fù)責(zé)一個(gè)簡單的單表查詢返回結(jié)構(gòu)體或切片。這樣的好處是每個(gè)查詢都可以獨(dú)立做緩存獨(dú)立測試獨(dú)立優(yōu)化。比如有一個(gè)訂單列表的用例需要返回訂單信息和買家昵稱。先定義兩個(gè) Repositorytype OrderRepo struct { db *sql.DB } type UserRepo struct { db *sql.DB } func (r *OrderRepo) ListByStatus(ctx context.Context, status int, limit, offset int) ([]Order, error) { rows, err : r.db.QueryContext(ctx, SELECT id, user_id, product_id, amount, status FROM orders WHERE status ? ORDER BY created_at DESC LIMIT ? OFFSET ?, status, limit, offset) // ... } func (r *UserRepo) BatchGetByIDs(ctx context.Context, ids []int64) (map[int64]User, error) { // 使用 IN 查詢批量獲取 }你可能會(huì)問這樣豈不是每個(gè)接口都要寫好幾遍查詢邏輯其實(shí)不會(huì)。批量查詢是高度復(fù)用的方法比如BatchGetByIDs可以被訂單列表、評論列表、售后列表同時(shí)使用。維護(hù)一份查詢邏輯比在每個(gè)接口里寫一段多表 join 要安全得多。4.2 多次查詢 內(nèi)存聚合的標(biāo)準(zhǔn)姿勢拆成多次查詢后最關(guān)鍵的點(diǎn)是在應(yīng)用層做聚合而不是循環(huán)里逐條查詢。很多人拆到一半又寫出了 N1 查詢性能比 join 還差。正確的姿勢是先查主數(shù)據(jù)收集關(guān)聯(lián) ID再批量查關(guān)聯(lián)數(shù)據(jù)最后在內(nèi)存里組裝。我在項(xiàng)目里的標(biāo)準(zhǔn)寫法差不多這樣func GetOrderDetails(ctx context.Context, status int, limit, offset int) ([]OrderDetail, error) { orders, err : orderRepo.ListByStatus(ctx, status, limit, offset) if err ! nil { return nil, err } userIDs : make([]int64, 0, len(orders)) productIDs : make([]int64, 0, len(orders)) userIDSet : make(map[int64]struct{}) productIDSet : make(map[int64]struct{}) for _, o : range orders { if _, ok : userIDSet[o.UserID]; !ok { userIDSet[o.UserID] struct{}{} userIDs append(userIDs, o.UserID) } if _, ok : productIDSet[o.ProductID]; !ok { productIDSet[o.ProductID] struct{}{} productIDs append(productIDs, o.ProductID) } } userMap, err : userRepo.BatchGetByIDs(ctx, userIDs) if err ! nil { return nil, err } productMap, err : productRepo.BatchGetByIDs(ctx, productIDs) if err ! nil { return nil, err } details : make([]OrderDetail, 0, len(orders)) for _, o : range orders { details append(details, OrderDetail{ Order: o, userName: userMap[o.UserID].Name, product: productMap[o.ProductID].Title, }) } return details, nil }這段代碼的邏輯是先查訂單列表再把所有 user_id 和 product_id 收集成兩個(gè)去重后的切片分別批量查詢最后用 map 做關(guān)聯(lián)。整個(gè)過程只查三張表每張表都是簡單查詢就算訂單表有 500 萬行只要 where 條件能把結(jié)果集過濾到幾十條性能就是可控的。這里有幾個(gè)細(xì)節(jié)值得注意。批量查詢的IN條件如果太長MySQL 可能會(huì)因?yàn)樗饕鶖?shù)估算不準(zhǔn)而走全表掃描建議分批查詢比如每批 500 個(gè) ID。同時(shí)去重很重要否則一個(gè)用戶有 200 個(gè)訂單你就把同一個(gè)用戶查了 200 遍雖然拉出來是同一個(gè)用戶但無謂地增加了查詢的壓力。4.3 使用 sqlc/GORM 時(shí)怎么避免隱式 JoinGolang 生態(tài)里很多人用 GORM 或 sqlc 操作數(shù)據(jù)庫。GORM 的Preload方法其實(shí)已經(jīng)幫你把 join 拆成了多條查詢默認(rèn)實(shí)現(xiàn)是先查主表再根據(jù)主表的 ID 去查關(guān)聯(lián)表本質(zhì)就是我們上面說的批量查詢加內(nèi)存聚合。但 GORM 也有坑比如預(yù)加載嵌套層級(jí)太深或者循環(huán)里使用Association方法照樣會(huì)產(chǎn)生 N1 查詢。如果你用 sqlc它本身不關(guān)心你是 join 還是分次查詢它只是把你寫的 SQL 轉(zhuǎn)換成 Go 代碼。這種情況下我建議你在 SQL 層面就要刻意控制 join 的使用別把需要跨表查詢的邏輯寫進(jìn)同一條 SQL 里。sqlc 生成的方法越簡單后續(xù)拆分和優(yōu)化就越容易。還有一個(gè)容易忽略的點(diǎn)事務(wù)邊界。如果你拆成多次查詢但要保證這些數(shù)據(jù)的強(qiáng)一致不能簡單地在應(yīng)用層分開查因?yàn)榉珠_查肯定有中間狀態(tài)。業(yè)務(wù)系統(tǒng)一般不建議追求強(qiáng)一致而是通過最終一致性來解決。比如訂單支付后把支付結(jié)果寫入訂單表同時(shí)異步推送商品銷量更新只要最終商品銷量是對的就不需要在一個(gè)事務(wù)里同時(shí)鎖住訂單表和商品表。這個(gè)思想比任何框架選型都重要。5. Python 應(yīng)用里的 Join 替代方案附代碼5.1 ORM 的 select_related 和 prefetch_related 別亂用Python 生態(tài)里Django 和 SQLAlchemy 是主流 ORM它們提供了非常方便的關(guān)聯(lián)加載方法但也正是因?yàn)榉奖愫芏嗳税阉鼈冇贸闪诵阅軞⑹?。Django 的select_related是通過 SQL join 實(shí)現(xiàn)的適合一對一和一對多外鍵關(guān)系比如order.user。它會(huì)一次性把關(guān)聯(lián)的表 join 出來如果你只查少數(shù)幾條主記錄效果很好。但如果你查了一個(gè) 10000 條記錄的 querysetselect_related會(huì)把所有關(guān)聯(lián)表也 join 進(jìn)來返回大量冗余列網(wǎng)絡(luò)和內(nèi)存都會(huì)爆炸。prefetch_related則是先查主表再查詢關(guān)聯(lián)表在 Python 內(nèi)存里完成關(guān)聯(lián)這個(gè)邏輯其實(shí)和我們在 Golang 里手動(dòng)做的聚合是一致的。但它的缺陷在于每次prefetch_related都會(huì)額外執(zhí)行幾條 SQL如果預(yù)加載層級(jí)很多比如prefetch_related(items__product__category)查詢數(shù)量會(huì)成倍增加。所以我的建議是Django ORM 只適合簡單的兩級(jí)關(guān)聯(lián)超過兩級(jí)就手動(dòng)寫bulk查詢不要迷信 ORM 的“魔法”。我見過一個(gè)后臺(tái)列表接口Django ORM 自動(dòng)預(yù)加載了訂單、商品、用戶、店鋪四層關(guān)系結(jié)果接口讀取了十幾張表的數(shù)據(jù)頁面加載要 8 秒。改造后用批量查詢加內(nèi)存字典合并接口降到 500ms。5.2 用批量查詢和內(nèi)存聚合替代 Join在 Python 業(yè)務(wù)代碼里我推薦先查主表再批量獲取關(guān)聯(lián)表數(shù)據(jù)最后構(gòu)建一個(gè)字典來映射。這和 Golang 的做法完全一致只是語法更簡潔。orders list(Order.objects.filter(status1)[:20]) user_ids list({o.user_id for o in orders}) product_ids list({o.product_id for o in orders}) users User.objects.filter(id__inuser_ids) user_map {u.id: u for u in users} products Product.objects.filter(id__inproduct_ids) product_map {p.id: p for p in products} result [] for order in orders: result.append({ order_id: order.id, user_name: user_map[order.user_id].name, product_title: product_map[order.product_id].title, })這個(gè)寫法保證了查詢次數(shù)固定是 3 次不會(huì)隨著訂單條數(shù)增長而增長。更重要的是這三條查詢都能利用數(shù)據(jù)庫索引單表查詢的性能非常好預(yù)測。如果以后訂單表拆分到獨(dú)立的庫你只需要修改Order的 Model 指向新庫其他代碼完全不用動(dòng)。對于那些必須實(shí)時(shí)展示的接口還可以把最終結(jié)果緩存到 Redis 里key 比如order:list:status:1:page:1過期時(shí)間設(shè) 60 秒。這樣即使底層查詢再慢用戶也不會(huì)直接感知到數(shù)據(jù)庫壓力。當(dāng)然緩存失效策略要設(shè)計(jì)好否則會(huì)出現(xiàn)數(shù)據(jù)延遲這個(gè)在業(yè)務(wù)上能不能接受要提前評估。5.3 asyncio 并發(fā)批量查詢需要注意的坑Python 3.8 以后async/await越來越普及很多人喜歡用 asyncio.gather 同時(shí)發(fā)多個(gè)數(shù)據(jù)庫查詢希望用并發(fā)替代 join。思路是對的但坑也很多。比如同時(shí)發(fā)幾十個(gè)查詢每個(gè)查詢都要占用一個(gè)數(shù)據(jù)庫連接如果連接池太小反而會(huì)因?yàn)榕抨?duì)導(dǎo)致請求更慢。我建議你只在“批量獲取多個(gè)關(guān)聯(lián) ID 的明細(xì)”這一步使用并發(fā)并且限制并發(fā)數(shù)。用asyncio.Semaphore控制同時(shí)執(zhí)行的查詢數(shù)量避免瞬間把連接池打滿。另外數(shù)據(jù)庫驅(qū)動(dòng)要選支持異步的版本Django 可以配async模式但底層數(shù)據(jù)庫連接依然是同步的不配合連接池效果并不好。還有一個(gè)更容易被忽略的點(diǎn)如果你用了asyncio.gather去并發(fā)查詢但其中一個(gè)查詢失敗其他查詢可能已經(jīng)執(zhí)行了這樣會(huì)留下不完整的狀態(tài)。最好是在全部查詢成功后再更新數(shù)據(jù)或者通過事務(wù)把幾個(gè)查詢包起來。但對于只讀查詢即使有一個(gè)失敗重試整個(gè)請求并不會(huì)造成數(shù)據(jù)問題所以也不必過于緊張。6. 工程落地拆 Join 的決策流程與補(bǔ)償機(jī)制6.1 拆 Join 的通用決策流程面對一條復(fù)雜的多表 join我建議按下面的步驟判斷要不要拆先看查詢條件能不能把驅(qū)動(dòng)表的數(shù)據(jù)量壓縮到百條以內(nèi)。如果能join 大概率沒問題。再看關(guān)聯(lián)字段有沒有索引。沒有索引哪怕驅(qū)動(dòng)表數(shù)據(jù)量小也可能拿到一條慢查詢。然后看這個(gè)查詢在不在核心鏈路。如果用戶每次下單都會(huì)命中它就必須嚴(yán)格控制響應(yīng)時(shí)間。如果查詢的表分屬不同業(yè)務(wù)模塊優(yōu)先拆開。等將來分庫分表你會(huì)感謝這個(gè)決定。如果拆開以后需要多次查詢才能搞定數(shù)據(jù)聚合就設(shè)計(jì)好批量查詢和緩存避免出現(xiàn) N1。上線前用 EXPLAIN 和執(zhí)行計(jì)劃驗(yàn)證別憑感覺。這個(gè)流程是我在實(shí)際項(xiàng)目中反復(fù)使用的。拆 join 不是目的目的是讓數(shù)據(jù)訪問模式可控。之前我們拆過一個(gè)用戶維度的匯總報(bào)表原來一條 SQL 同時(shí) join 了訂單表和退款表跑了 20 秒。拆開后先查詢訂單表再用退款表批量查詢應(yīng)用層做合并報(bào)表時(shí)間降到 2 秒。同樣是拿到結(jié)果數(shù)據(jù)庫的壓力卻小了非常多。6.2 數(shù)據(jù)不一致時(shí)的補(bǔ)償方案把 join 拆成多次查詢以后最讓人擔(dān)心的就是數(shù)據(jù)一致性。比如你先查了訂單表再查用戶表結(jié)果用戶在這中間改了昵稱你返回的還是舊昵稱。這在大部分業(yè)務(wù)系統(tǒng)里是可以接受的畢竟用戶昵稱不是強(qiáng)一致數(shù)據(jù)。真正需要在意的是訂單金額、庫存這類數(shù)據(jù)不能有偏差。我的經(jīng)驗(yàn)是把強(qiáng)一致的數(shù)據(jù)放在同一張表或同一個(gè)聚合里用數(shù)據(jù)庫事務(wù)保證把弱一致的數(shù)據(jù)拆開通過消息隊(duì)列、定時(shí)任務(wù)或者版本號(hào)做最終一致。比如下單扣庫存訂單和庫存是強(qiáng)相關(guān)的必須在一個(gè)事務(wù)里處理而訂單和用戶昵稱則沒關(guān)系拆開完全不影響業(yè)務(wù)正確性。有些團(tuán)隊(duì)會(huì)用本地消息表來保證一致性應(yīng)用先把業(yè)務(wù)操作寫入業(yè)務(wù)表同時(shí)寫一條“待處理消息”到本地消息表然后異步任務(wù)掃描消息表把數(shù)據(jù)同步到其他模塊。這種方式簡單可靠不需要引入重量級(jí)中間件也能滿足大部分場景。等系統(tǒng)規(guī)模大到需要引入消息隊(duì)列時(shí)再平滑遷移即可。6.3 上線前必須做的三件事別等線上慢查詢告警了才開始調(diào)優(yōu)。每次涉及 join 變更我強(qiáng)烈建議上線前做三件事開啟慢查詢?nèi)罩居?EXPLAIN 分析執(zhí)行計(jì)劃做一次最簡單的壓測。慢查詢?nèi)罩灸芨嬖V你哪些 SQL 超過了閾值比如long_query_time1就是 1 秒以上記錄。通過日志找到最耗時(shí)的查詢再用EXPLAIN看它的執(zhí)行計(jì)劃重點(diǎn)關(guān)注 type 字段如果從ALL全表掃描變成ref或eq_ref說明索引起了作用如果出現(xiàn)Using temporary或Using filesort意味著 MySQL 在處理排序或臨時(shí)表需要進(jìn)一步優(yōu)化。壓測也很重要。不需要復(fù)雜的工具用一個(gè)簡單的腳本模擬 100 個(gè)并發(fā)用戶調(diào)用接口觀察數(shù)據(jù)庫連接數(shù)和響應(yīng)時(shí)間。如果你拆成多次查詢后數(shù)據(jù)庫連接數(shù)依然穩(wěn)定說明架構(gòu)是健康的如果連接數(shù)飆升那就要考慮加連接池或減少查詢次數(shù)了。上線前這些工作花不了太多時(shí)間卻能避免線上很多尷尬。7. 實(shí)戰(zhàn)排查慢 Join 的處理技巧與踩坑記錄7.1 一條慢 Join 的排查實(shí)錄之前我接手過一個(gè)電商后臺(tái)的訂單查詢接口用戶反饋響應(yīng)越來越慢。我打開慢查詢?nèi)罩景l(fā)現(xiàn)一條 SQL 要跑 4 秒SELECT o.id, o.order_no, u.phone, p.title FROM orders o LEFT JOIN users u ON o.user_id u.id LEFT JOIN products p ON o.product_id p.id ORDER BY o.created_at DESC LIMIT 20;第一眼看上去很合理只取 20 條還有LIMIT。真正的問題在于ORDER BY o.created_at DESC在orders表上沒有合適的索引MySQL 只能先把所有滿足條件的行排序再取 20 條。即使訂單只有 50 萬行這個(gè)排序也很消耗性能。我讓開發(fā)同學(xué)給orders(created_at, id)加了一個(gè)聯(lián)合索引查詢立刻降到 80ms。加索引之后EXPLAIN的 type 從ALL變成了rangeExtra 里也不再出現(xiàn)Using filesort。這就是一個(gè)典型的“join 不背鍋索引沒到位才背鍋”的例子。7.2 容易踩的坑LEFT JOIN 與 INNER JOIN 結(jié)果不一致有不少同學(xué)分不清LEFT JOIN和INNER JOIN。比如查詢所有訂單然后 LEFT JOIN 用戶表想顯示“即使是已注銷的用戶也要顯示訂單”。這個(gè)思路沒問題但如果你在 WHERE 里加了u.status 1那么 LEFT JOIN 就退化成 INNER JOIN 了已注銷用戶的訂單就消失了。SELECT o.id, u.name FROM orders o LEFT JOIN users u ON o.user_id u.id WHERE u.status 1這個(gè)寫法是錯(cuò)誤的。如果想保留訂單且過濾用戶狀態(tài)應(yīng)該把條件放到ON子句里SELECT o.id, u.name FROM orders o LEFT JOIN users u ON o.user_id u.id AND u.status 1類似的坑還出現(xiàn)在多表 join 后做分頁統(tǒng)計(jì)時(shí)。兩表關(guān)聯(lián)會(huì)產(chǎn)生笛卡爾積如果一對多關(guān)系導(dǎo)致訂單行數(shù)被放大再去COUNT(*)就會(huì)得到錯(cuò)誤數(shù)量。這種問題用 join 很難直觀發(fā)現(xiàn)等你查出來的數(shù)據(jù)對不上賬再去排查就非常麻煩了。拆成多次查詢后統(tǒng)計(jì)邏輯是各自獨(dú)立的反而更容易看清楚。7.3 我的幾個(gè)實(shí)操心得我在項(xiàng)目里處理 join 問題已經(jīng)很多年了最后分享幾個(gè)個(gè)人體會(huì)。第一如果一段查詢邏輯里出現(xiàn)了三個(gè)以上的 join我基本會(huì)停下來重新審視是不是數(shù)據(jù)建模有問題而不是急著去調(diào)優(yōu) SQL。第二拆查詢之前先把“需要的數(shù)據(jù)范圍”想清楚不要一次把整張表的所有字段都撈出來減少網(wǎng)絡(luò)傳輸量和應(yīng)用內(nèi)存占用。第三無論用 Golang 還是 Python內(nèi)存聚合的代碼一定要寫在 Service 層不要散落在 Handler 或視圖函數(shù)里否則后續(xù)維護(hù)會(huì)很痛苦。還有一個(gè)心得是如果業(yè)務(wù)模塊之間確實(shí)需要頻繁地聯(lián)表查詢那說明它們在業(yè)務(wù)上可能本就不該分得太開。這時(shí)候更值得考慮的是調(diào)整數(shù)據(jù)模型比如把經(jīng)常一起查詢的字段冗余到同一張表里而不是繼續(xù)在查詢層做文章。畢竟解決一個(gè)問題最好的方式是從源頭避免它而不是等它變成事故再救火。做技術(shù)選型和 SQL 設(shè)計(jì)時(shí)把 join 當(dāng)成一把錘子別把所有問題都當(dāng)成釘子?？刂坪脭?shù)據(jù)訪問邊界關(guān)注數(shù)據(jù)庫的執(zhí)行代價(jià)結(jié)合應(yīng)用層的批量查詢和緩存整個(gè)業(yè)務(wù)系統(tǒng)才能睡得安穩(wěn)。