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