北京
991張表，15個模式，11個SQL數據庫加6個MongoDB實例。這是日本最大服裝租賃平臺airCloset攢了10年的技術債。CTO Ryan Tsuji最近攤牌：全公司沒一個人能摸清這張數據地圖。
客服問個簡單問題——"用戶顯示退貨完成了，倉庫真收到貨了嗎？"——能答上來的人用一只手數得過來。而且人家要是休假，這事就卡死。
問題不是找不到表名，是表與表之間的關系只存在特定人腦子里。
四張表、兩個庫、一個無外鍵的字符串匹配
拆解這個退貨查詢，路徑長得離譜。
App顯示的退貨狀態在aircloset庫的delivery_order表，狀態碼"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說得很直接：知道這條路的人，公司一只手數得過來。
這就是991張表×15個模式的日常。不是"我不知道表名"這種初級問題，是"這些表居然能連起來"這種拓撲知識，成了人形文檔。
MCP協議：把數據庫拓撲變成對話
Ryan Tsuji的解法叫DB Graph MCP，基于Anthropic去年發布的Model Context Protocol（模型上下文協議）。
簡單說，MCP讓AI助手能調用外部工具。DB Graph MCP就是這個思路的落地：把公司所有數據庫的schema、表關系、字段語義，建成一張可查詢的圖。
員工打開Claude Code，直接問自然語言。"找跟退貨處理確認相關的表"，底層調用search_tables做語義搜索，返回相關表名、字段、甚至跨庫連接路徑。
不需要知道表名。不需要知道哪個庫。更不需要知道那個varchar字符串匹配的黑魔法。
工具返回格式很實在：表名、所屬schema、字段列表、字段類型、描述、與其他表的關聯關系。如果是跨庫查詢，會把join路徑標出來。
查詢生產數據？可以，但有安全閘。
Ryan Tsuji強調能安全查生產環境。權限層做了隔離：自然語言查詢先經過schema檢索，生成SQL后走只讀副本，敏感字段脫敏。不是讓人直接對主庫跑random query。
圖是怎么建的：自動化掃描+人工標注
10年積累的數據庫，不可能手工錄。DB Graph的構建分兩層：
第一層自動化。掃描所有數據庫的information_schema，提取表結構、字段類型、外鍵關系（如果有的話）、索引信息。SQL和MongoDB統一抽象成節點和邊。
第二層人工補漏。那些varchar字符串匹配的黑魔法，外鍵掃描掃不出來。需要業務專家標注："這個字段實際上等于那個庫的某個字段"。
Ryan Tsuji沒透露具體比例，但從案例推斷，跨庫隱式關聯占了不少。這類知識原本只存在老員工腦子里，現在被編碼進圖里。
圖的存儲結構他沒細說，但語義搜索的能力暗示用了向量嵌入。表名、字段名、描述文本向量化，自然語言查詢做相似度匹配。
為什么是現在：LLM讓"自然語言到SQL"終于可用
自然語言查數據庫不是新想法。十年前就有NL2SQL研究，但準確率感人，沒人敢上生產。
Ryan Tsuji的判斷是：大語言模型讓語義理解躍遷，但光有模型不夠，需要結構化上下文。MCP協議的價值就在這里——給模型一個標準化的"手"，去抓數據庫的元數據。
DB Graph MCP的架構分三塊：元數據采集器、圖存儲與索引、MCP服務器。MCP服務器暴露給Claude Code三個核心工具：search_tables（語義搜表）、get_table_schema（查表結構）、execute_query（執行只讀查詢）。
execute_query不是直接跑用戶輸入，而是基于前兩個工具的上下文，由模型生成SQL，再經審核層。Ryan Tsuji強調"安全"多次，顯然吃過生產事故的虧。
一個細節：他們沒做自然語言直接生成SQL。
路徑是"自然語言→找表→確認schema→生成SQL"。多了一步人工確認，但換來可控性。991張表的復雜度，一步到位的NL2SQL風險太高。
給同行的參考：從0到1的成本
Ryan Tsuji沒公開具體投入，但從技術棧可以估算。airCloset用Python建MCP服務器，圖數據庫選型沒提，但語義搜索部分大概率接的現成向量庫。
真正的成本在人工標注。那些跨庫varchar匹配，需要懂業務的老員工坐下來，一條條確認"這等于那"。這是知識提取的硬成本，技術替代不了。
但他也給了個樂觀信號：建好之后，維護是自動化的。schema變更通過CDC（變更數據捕獲）實時同步，新表自動入圖，字段描述繼承歷史標注。
10年老系統的數據治理，從人形文檔轉向可查詢的基礎設施。這個轉型成本，Ryan Tsuji認為是值得的——客服不用再等那個"一只手數得過來"的人休假回來。
最后留個開放問題：你的公司有多少張表？有多少連接路徑只存在特定人腦子里？如果這個人明天離職，有多少查詢會卡死？
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
