10年積累的數(shù)據(jù)庫(kù)架構(gòu)，最終變成了15個(gè)庫(kù)、991張表、6個(gè)MongoDB實(shí)例的迷宮。airCloset的CTO Ryan Tsuji發(fā)現(xiàn)，公司能完整畫出跨庫(kù)查詢路徑的人，一只手?jǐn)?shù)得過來。

客服問了個(gè)簡(jiǎn)單問題："用戶看到退貨已完成，倉(cāng)庫(kù)真的確認(rèn)收貨了嗎？"答案藏在4張表里，橫跨2個(gè)數(shù)據(jù)庫(kù)，靠一個(gè)varchar字段硬連——沒有外鍵，沒有文檔，只有某個(gè)老員工腦子里的映射關(guān)系。

這種查詢路徑的"人腦依賴癥"，在991張表的世界里每天都在上演。

從"問對(duì)人"到"直接問"：DB Graph MCP做了什么

Tsuji團(tuán)隊(duì)做的不是又一個(gè)BI工具。DB Graph MCP是一個(gè)模型上下文協(xié)議（MCP）服務(wù)器，接在Claude Code后面，讓任何人用自然語(yǔ)言直接查詢這991張表。

不需要知道表名。輸入"find tables related to returns"，系統(tǒng)會(huì)跨所有15個(gè)schema做語(yǔ)義搜索，返回相關(guān)表結(jié)構(gòu)、字段含義、以及——最關(guān)鍵的——表與表之間的連接路徑。

那個(gè)讓客服頭疼的退貨確認(rèn)問題，現(xiàn)在變成一句話："查詢用戶ID為XXX的退貨，倉(cāng)庫(kù)端是否已確認(rèn)收貨。"Claude Code會(huì)自己調(diào)用search_tables找到delivery_order表，再沿著warehouse_mapping跳到bridge庫(kù)的receive_record，最后拼出答案。

整個(gè)過程不需要用戶知道bridge庫(kù)的存在，更不需要記得那個(gè)varchar字段叫warehouse_order_code還是shipping_order_code。

技術(shù)實(shí)現(xiàn)上，DB Graph先對(duì)所有表結(jié)構(gòu)做向量化索引。用戶查詢時(shí)，search_tables工具做語(yǔ)義匹配；需要具體數(shù)據(jù)時(shí)，query_data工具生成并執(zhí)行SQL。兩個(gè)工具的組合，把"找表"和"查數(shù)"解耦了。

為什么不用現(xiàn)成的數(shù)據(jù)目錄工具

市面上不是沒解決方案。Tableau、Looker、各種數(shù)據(jù)字典工具，本質(zhì)上都在做同一件事：讓懂?dāng)?shù)據(jù)的人把知識(shí)結(jié)構(gòu)化，再分享給不懂的人。

Tsuji的觀察是——這條路在991張表面前會(huì)失效。不是文檔寫不完，是表之間的關(guān)系變化比文檔更新快。更致命的是，那些跨庫(kù)的連接邏輯（比如那個(gè)varchar硬連）從來就沒進(jìn)過文檔，只存在于寫過這段代碼的人腦子里。

DB Graph的解法是把"關(guān)系"也變成可搜索的。系統(tǒng)不僅索引表結(jié)構(gòu)，還構(gòu)建了表與表之間的關(guān)聯(lián)圖：哪些表共享字段名、哪些有外鍵約束、哪些經(jīng)常出現(xiàn)在同一段業(yè)務(wù)邏輯里。語(yǔ)義搜索時(shí)，這些關(guān)聯(lián)權(quán)重會(huì)參與排序。

換句話說，系統(tǒng)猜的不只是"哪張表可能有退貨數(shù)據(jù)"，還包括"從這張表怎么走到倉(cāng)庫(kù)確認(rèn)表"。

安全層面，MCP服務(wù)器做了硬性隔離。生產(chǎn)數(shù)據(jù)查詢走只讀副本，敏感字段脫敏，操作日志全量審計(jì)。Tsuji強(qiáng)調(diào)：能問問題不等于能看所有數(shù)據(jù)，權(quán)限體系還是原來的權(quán)限體系。

一個(gè)具體場(chǎng)景的完整還原

回到那個(gè)退貨確認(rèn)問題。DB Graph MCP的實(shí)際響應(yīng)長(zhǎng)什么樣？

用戶輸入："查詢用戶ID 12345的退貨，倉(cāng)庫(kù)是否已確認(rèn)收貨。"

Claude Code先調(diào)用search_tables，返回相關(guān)表及關(guān)聯(lián)路徑：

— aircloset.delivery_order（訂單主表，status字段標(biāo)記RETURNED）
— aircloset.warehouse_mapping（映射表，warehouse_order_code字段）
— bridge.shipping_order（物流表，shipping_order_code字段匹配）
— bridge.receive_record（收貨表，status=COMPLETE表示倉(cāng)庫(kù)確認(rèn)）

系統(tǒng)同時(shí)標(biāo)注：aircloset與bridge為不同數(shù)據(jù)庫(kù)，連接依賴varchar字段匹配，無外鍵約束。

確認(rèn)路徑后，query_data生成SQL并執(zhí)行，返回最終結(jié)果：該用戶3筆退貨中，2筆倉(cāng)庫(kù)狀態(tài)為COMPLETE，1筆仍為PENDING——雖然App端都顯示"已完成"。

這個(gè)查詢路徑，之前只有3個(gè)老員工能獨(dú)立完成?，F(xiàn)在客服一線可以直接問。

991張表背后的組織代價(jià)

airCloset 2015年創(chuàng)業(yè)，從單體架構(gòu)走到微服務(wù)，數(shù)據(jù)庫(kù)跟著業(yè)務(wù)線拆分。10年下來，技術(shù)債的利息不是慢查詢，是"找誰問"的協(xié)作成本。

Tsuji算過一筆賬：一個(gè)中等復(fù)雜度的跨庫(kù)問題，平均要轉(zhuǎn)3-4個(gè)人才能找到能回答的人。如果關(guān)鍵人休假或離職，問題就掛起。這種隱性阻塞，在快速迭代的業(yè)務(wù)里每天都在發(fā)生。

DB Graph MCP不是消滅專家，是把專家腦子里的"路徑知識(shí)"變成基礎(chǔ)設(shè)施。就像地圖軟件把老司機(jī)認(rèn)路的能力普惠給所有人——你不需要記得哪條路近，只需要輸入目的地。

項(xiàng)目開源在GitHub上，Tsuji提供了完整的部署指南和權(quán)限配置模板。但他也提醒：這套方案假設(shè)你的表結(jié)構(gòu)有基本規(guī)范，字段命名別太隨意。語(yǔ)義搜索再?gòu)?qiáng)，也救不了全叫f1、f2、f3的字段名。

如果讓你用自然語(yǔ)言查詢自己公司的數(shù)據(jù)庫(kù)，你第一句想問什么？