991張表，15個模式，11個SQL數(shù)據(jù)庫加6個MongoDB實例。這是日本最大服裝租賃平臺airCloset攢了10年的技術債。CTO Ryan Tsuji最近攤牌：全公司沒一個人能摸清這張數(shù)據(jù)地圖。

客服問個簡單問題——"用戶顯示退貨完成了，倉庫真收到貨了嗎？"——能答上來的人用一只手數(shù)得過來。而且人家要是休假，這事就卡死。

問題不是找不到表名，是表與表之間的關系只存在特定人腦子里。

四張表、兩個庫、一個無外鍵的字符串匹配

拆解這個退貨查詢，路徑長得離譜。

App顯示的退貨狀態(tài)在aircloset庫的delivery_order表，狀態(tài)碼"RETURNED"就算完成。但倉庫實際確認在另一個叫bridge的庫里，receive_record表的"COMPLETE"才是真金白銀的物理收貨。

兩個庫之間沒有外鍵。唯一的連接是aircloset里一張映射表，存著warehouse_order_code——一個varchar字符串，得去bridge庫的shipping_order表按字符串匹配shipping_order_code。

aircloset delivery_order → aircloset映射表（varchar）→ bridge shipping_order（字符串匹配）→ bridge receive_record。

四張表，跨兩個模式，靠一個無索引保障的字符串字段勾連。Ryan Tsuji說得很直接：知道這條路的人，公司一只手數(shù)得過來。

這就是991張表×15個模式的日常。不是"我不知道表名"這種初級問題，是"這些表居然能連起來"這種拓撲知識，成了人形文檔。

MCP協(xié)議：把數(shù)據(jù)庫拓撲變成對話

Ryan Tsuji的解法叫DB Graph MCP，基于Anthropic去年發(fā)布的Model Context Protocol（模型上下文協(xié)議）。

簡單說，MCP讓AI助手能調(diào)用外部工具。DB Graph MCP就是這個思路的落地：把公司所有數(shù)據(jù)庫的schema、表關系、字段語義，建成一張可查詢的圖。

員工打開Claude Code，直接問自然語言。"找跟退貨處理確認相關的表"，底層調(diào)用search_tables做語義搜索，返回相關表名、字段、甚至跨庫連接路徑。

不需要知道表名。不需要知道哪個庫。更不需要知道那個varchar字符串匹配的黑魔法。

工具返回格式很實在：表名、所屬schema、字段列表、字段類型、描述、與其他表的關聯(lián)關系。如果是跨庫查詢，會把join路徑標出來。

查詢生產(chǎn)數(shù)據(jù)？可以，但有安全閘。

Ryan Tsuji強調(diào)能安全查生產(chǎn)環(huán)境。權限層做了隔離：自然語言查詢先經(jīng)過schema檢索，生成SQL后走只讀副本，敏感字段脫敏。不是讓人直接對主庫跑random query。

圖是怎么建的：自動化掃描+人工標注

10年積累的數(shù)據(jù)庫，不可能手工錄。DB Graph的構建分兩層：

第一層自動化。掃描所有數(shù)據(jù)庫的information_schema，提取表結構、字段類型、外鍵關系（如果有的話）、索引信息。SQL和MongoDB統(tǒng)一抽象成節(jié)點和邊。

第二層人工補漏。那些varchar字符串匹配的黑魔法，外鍵掃描掃不出來。需要業(yè)務專家標注："這個字段實際上等于那個庫的某個字段"。

Ryan Tsuji沒透露具體比例，但從案例推斷，跨庫隱式關聯(lián)占了不少。這類知識原本只存在老員工腦子里，現(xiàn)在被編碼進圖里。

圖的存儲結構他沒細說，但語義搜索的能力暗示用了向量嵌入。表名、字段名、描述文本向量化，自然語言查詢做相似度匹配。

為什么是現(xiàn)在：LLM讓"自然語言到SQL"終于可用

自然語言查數(shù)據(jù)庫不是新想法。十年前就有NL2SQL研究，但準確率感人，沒人敢上生產(chǎn)。

Ryan Tsuji的判斷是：大語言模型讓語義理解躍遷，但光有模型不夠，需要結構化上下文。MCP協(xié)議的價值就在這里——給模型一個標準化的"手"，去抓數(shù)據(jù)庫的元數(shù)據(jù)。

DB Graph MCP的架構分三塊：元數(shù)據(jù)采集器、圖存儲與索引、MCP服務器。MCP服務器暴露給Claude Code三個核心工具：search_tables（語義搜表）、get_table_schema（查表結構）、execute_query（執(zhí)行只讀查詢）。

execute_query不是直接跑用戶輸入，而是基于前兩個工具的上下文，由模型生成SQL，再經(jīng)審核層。Ryan Tsuji強調(diào)"安全"多次，顯然吃過生產(chǎn)事故的虧。

一個細節(jié)：他們沒做自然語言直接生成SQL。

路徑是"自然語言→找表→確認schema→生成SQL"。多了一步人工確認，但換來可控性。991張表的復雜度，一步到位的NL2SQL風險太高。

給同行的參考：從0到1的成本

Ryan Tsuji沒公開具體投入，但從技術?？梢怨浪恪irCloset用Python建MCP服務器，圖數(shù)據(jù)庫選型沒提，但語義搜索部分大概率接的現(xiàn)成向量庫。

真正的成本在人工標注。那些跨庫varchar匹配，需要懂業(yè)務的老員工坐下來，一條條確認"這等于那"。這是知識提取的硬成本，技術替代不了。

但他也給了個樂觀信號：建好之后，維護是自動化的。schema變更通過CDC（變更數(shù)據(jù)捕獲）實時同步，新表自動入圖，字段描述繼承歷史標注。

10年老系統(tǒng)的數(shù)據(jù)治理，從人形文檔轉向可查詢的基礎設施。這個轉型成本，Ryan Tsuji認為是值得的——客服不用再等那個"一只手數(shù)得過來"的人休假回來。

最后留個開放問題：你的公司有多少張表？有多少連接路徑只存在特定人腦子里？如果這個人明天離職，有多少查詢會卡死？