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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一個具體場景的完整還原

回到那個退貨確認問題。DB Graph MCP的實際響應(yīng)長什么樣？

用戶輸入："查詢用戶ID 12345的退貨，倉庫是否已確認收貨。"

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

— aircloset.delivery_order（訂單主表，status字段標記RETURNED）
— aircloset.warehouse_mapping（映射表，warehouse_order_code字段）
— bridge.shipping_order（物流表，shipping_order_code字段匹配）
— bridge.receive_record（收貨表，status=COMPLETE表示倉庫確認）

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

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

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

991張表背后的組織代價

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

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

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

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

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