日本公司991張表沒人能記全，CTO用自然語言給數據庫開了扇后門

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

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

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

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

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

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

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

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

技術實現上，DB Graph先對所有表結構做向量化索引。用戶查詢時，search_tables工具做語義匹配；需要具體數據時，query_data工具生成并執行SQL。兩個工具的組合，把"找表"和"查數"解耦了。

為什么不用現成的數據目錄工具

市面上不是沒解決方案。Tableau、Looker、各種數據字典工具，本質上都在做同一件事：讓懂數據的人把知識結構化，再分享給不懂的人。

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

DB Graph的解法是把"關系"也變成可搜索的。系統不僅索引表結構，還構建了表與表之間的關聯圖：哪些表共享字段名、哪些有外鍵約束、哪些經常出現在同一段業務邏輯里。語義搜索時，這些關聯權重會參與排序。

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

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

一個具體場景的完整還原

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

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

Claude Code先調用search_tables，返回相關表及關聯路徑：

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

系統同時標注：aircloset與bridge為不同數據庫，連接依賴varchar字段匹配，無外鍵約束。

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

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

991張表背后的組織代價

airCloset 2015年創業，從單體架構走到微服務，數據庫跟著業務線拆分。10年下來，技術債的利息不是慢查詢，是"找誰問"的協作成本。

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

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

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

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