让 AI 先读懂数据库结构再执行查询

AI 能连接数据库、执行 SQL，并不代表它已经理解了数据库。查出最近 30 天新增的客户，和解释客户表为什么这样设计、改一个字段会影响哪些过程，是两类不同的问题。

作者推荐用 SchemaCrawler AI MCP Server 补上结构信息，再与执行查询的数据库 MCP 配合。这个思路值得看：它把 AI 数据库助手的价值，从「能查到什么」推进到「改之前知道该检查什么」。但原文没有提供实测或对照数据，能力边界也需要分清。

能跑 SQL，为什么还会看不懂数据库

面对陌生数据库，困难往往不是写一条查询，而是弄清楚表背后的业务关系。

例如，CUSTOMER_STATUS_CD 为什么存在？XREF 前缀代表什么？哪些存储过程引用了某张表？改一个列会影响哪里？这些问题需要的是元数据（metadata），也就是描述数据库结构的信息，查询结果本身通常回答不了。

原文列出的结构信息包括外键和关系、视图、触发器、存储过程、函数、约束、索引，以及对象之间的依赖。命名约定和领域模型同样重要：它们帮助开发者把数据库对象与业务概念对应起来。

查到数据，只能证明查询得到了结果，不能证明 AI 理解了业务模型。

例如，让助手查询最近 30 天创建的客户，重点是筛选数据；让它解释数据库设计，则需要知道客户与账户如何关联、哪些对象依赖客户表，以及这些关系能支持什么解释。

只给表名、列名，助手容易从命名猜含义。提供结构信息，至少能让解释建立在更多可检查的依据上。

两个 MCP 各管什么，改客户状态时就能看出来

SchemaCrawler 是用于数据库结构发现和文档化的工具。它的 MCP server 将表定义、关系、ER 模型结构、例程、触发器、DDL 和依赖信息提供给 AI 工作流。原文还提到，它使用图论建立聚类并推断设计领域，也就是根据对象之间的连接，寻找可能属于同一业务模块的对象群。

以 Orders 表为例，助手可以检查关联实体、外键，以及依赖这张表的数据库对象，再解释它在系统中的位置。

作者用下面的结构说明两个 MCP 如何协作，解决「结构探索与数据操作分别交给谁」的问题：

flowchart TD
    Agent["AI agent"]

    SchemaCrawler["SchemaCrawler AI MCP Server<br/>(Read-only - does not update database tables)<br/><br/>• schema metadata<br/>• strong and weak entities and relationships<br/>• dependencies<br/>• clusters and domains"]
    Database["Database MCP Server<br/><br/>• queries and data<br/>• diagnostics<br/>• administration"]

    Agent --> SchemaCrawler
    Agent --> Database

要看清的是 Read-only - does not update database tables 这一行。SchemaCrawler 在这里负责提供结构上下文，数据库 MCP 则承担它实际支持的查询、数据读取、诊断或管理操作。原文也明确提醒，各数据库 MCP 的能力并不相同。

假设需求是「新增一种客户状态，并更新应用」。查询型 MCP 可以帮助定位和修改相关数据；SchemaCrawler 则帮助寻找可能受影响的存储过程、触发器、视图和关系。

这一步很有价值。状态值可能改对了，但依赖旧状态集合的数据库逻辑仍然需要排查。助手如果只盯着数据行，就可能漏掉后续调查方向。

同样的思路适用于接手缺少文档的老系统、理解业务概念如何落表，以及数据库平台或云迁移。迁移不仅要搬数据，还要识别关系和依赖。结构元数据可以帮助列出需要检查的对象。

我的判断

我认同作者把「访问数据」和「理解结构」分开。对要参与改库的 AI 助手来说，后者值得放在操作之前。

不过，结构依赖能提示调查方向，不能证明业务意图，也不能自动证明改动安全。

作者自己承认，这个工具无法独自证明每个设计选择的原始意图。CUSTOMER_STATUS_CD 的用途，可以结合类型、约束、关系和引用对象推断；当年为什么这样设计，仍可能需要业务文档或维护者解释。

原文没有说明依赖识别的完整范围，也没有给出具体数据库平台上的覆盖情况。因此，不能把「没有发现依赖」当成「不存在影响」。对应用代码、动态生成的 SQL 等情况，文章也没有交代处理方式。

与人工查看 DDL、维护 ER 图相比，这种方案的吸引力是让 AI 能直接使用结构信息。但它是否更准确、能节省多少时间，原文没有对照数据，只能视为工具方案介绍和经验判断。

标题强调不要给 AI「盲目访问」，正文实际讨论的重点是上下文不足，并未展开权限控制、审批或审计设计。只读结构工具的边界，也不能代替整个操作链路的权限边界。

能拿来做什么

• 接手陌生数据库时，先让助手解释某个业务实体涉及哪些表、外键、视图和过程，并要求区分结构事实与业务推断，再继续追问设计原因。
• 修改客户状态或字段前，先生成一份数据库内的潜在影响清单，逐项检查相关触发器、视图和存储过程，再安排数据与应用修改。
• 为全栈项目配置数据库 AI 工具时，可以采用作者提出的分工：用 SchemaCrawler AI MCP Server 探索结构，用数据库专属 MCP 执行其支持的操作，并核对各自的实际能力。