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认为是值得的——客服不用再等那个"一只手数得过来"的人休假回来。
最后留个开放问题：你的公司有多少张表？有多少连接路径只存在特定人脑子里？如果这个人明天离职，有多少查询会卡死？
热门跟贴