数据库开发者为什么需要了解 MCP

核心思想：AI 与数据库之间坐着一个经纪人

MCP 是一种客户端-服务器协议。你的 AI 工具（Claude、Cursor、ChatGPT、VS Code，以及越来越多的其他工具）是客户端。另一端是 MCP 服务器——一个小型服务，它将一组特定的能力暴露为 AI 可以调用的"工具"。

重要的是这个服务器为数据库做了什么：它持有连接。AI 从来不需要收到你的凭证。它看到的是一份工具菜单——比如 list_tables、get_schema、run_query——然后调用它们。服务器负责认证数据库、执行操作，只把结果返回来。

把它想象成酒吧里的调酒师。你不会拿到酒库的钥匙；你点一杯酒，有钥匙的人给你倒。AI 提问；有数据库访问权限的经纪人回答问题。

以下是客户端在列出可用工具时大致看到的内容：

{
  "tools": [
    { "name": "list_databases", "description": "List accessible databases" },
    { "name": "get_schema",     "description": "Return tables and columns for a database" },
    { "name": "run_query",      "description": "Execute a read-only SQL SELECT" }
  ]
}

然后是一个典型的交换过程，从自然语言问题到真实 SQL：

User:  "How many trial users signed up last week but never activated?"

AI →   calls get_schema  → learns tables: users, subscriptions, events
AI →   calls run_query with:

       SELECT COUNT(*)
       FROM users u
       LEFT JOIN events e
         ON e.user_id = u.id AND e.name = 'activated'
       WHERE u.plan = 'trial'
         AND u.created_at >= NOW() - INTERVAL '7 days'
         AND e.id IS NULL;

Server → runs it against the DB, returns: 342

在这个过程中，AI 完全不需要你的数据库密码。它需要的是 schema（这样才能写出有效的 SQL）和一个运行查询的工具。这个分离就是整个机制的核心。

为什么这比表面看起来重要得多

一旦经纪人模式就位，一系列良好的属性几乎是免费获得的。

凭证不会进入提示词。当今秘密泄露最常见的方式就是进入聊天窗口。如果 AI 根本不需要它们，它们就不可能通过这种方式泄露。截至 2025 年中期的 MCP 规范，协议对认证服务器标准化了 OAuth 2.1，意味着访问可以是短命的、范围受限的、可集中撤销的，而不是一个粘贴到配置文件中的长期字符串。

设计层面的只读是可以强制执行的。一个构建良好的数据库 MCP 服务器可以拒绝任何非 SELECT 的操作。不允许 UPDATE、DROP、DELETE。这让 AI 可以自由探索你的数据——统计行数、分析列、测试假设——完全没有修改任何东西的风险。正确的做法是在数据库本身做备份：创建一个只有只读角色的专用用户，让服务器以该用户身份连接，这样即使有 bug 也无法写入。

-- The database enforces what the broker promises
CREATE ROLE ai_readonly LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE app TO ai_readonly;
GRANT USAGE ON SCHEMA public TO ai_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_readonly;
-- No INSERT/UPDATE/DELETE granted, ever

人不需要直接访问数据库。这是一个安静发生的胜利。技术支持工程师或创始人可以用英语提问并获得答案，而无需你为他们配置 psql 登录。提问的权限与连接的权限是解耦的。

行级安全可以与其组合使用。如果你的数据库已经使用了 RLS，这些策略对 AI 生成的查询也是透明应用的。将每个 MCP 连接指向一个 per-user 或 per-tenant 角色，AI 物理上就无法返回该角色看不到的行——无论提示词如何措辞。这使得"给每个客户提供只能访问他们自己数据的自然语言访问"成为一个可实现的功能，而不是一个可怕的风险。

Schema 感知能力消灭了大量幻觉

一个微妙的好处：因为 AI 可以在写 SQL 之前调用 get_schema，它基于你真实的表名和列名来工作，而不是靠猜测。AI 写 SQL 带来的一半挫败感——SELECT customer_name FROM clients 而你的表其实是 users、列是 full_name——源于模型不知道你的 schema。通过工具调用把 schema 提供给它，幻觉的表和列就会急剧减少。你是在将模型锚定在现实上，而不是希望它猜对你的命名约定。

没人提前提到的坑

MCP 解决了凭证泄露问题。它并不会神奇地让 AI 加数据库变得安全。有几件事需要牢记在心：

提示词注入是真实存在的，数据库是攻击面。如果你的 AI 代理读取不受信任的内容——支持工单、用户提交的记录、日志条目——攻击者可以在这些文本中嵌入指令。在 2025 年中期的一个事件中，一个拥有特权数据库访问权限的支持工单代理被人操纵去读取和泄露敏感令牌，因为它把来自数据库的数据当作可信的命令。代理无法区分数据和指令。防御措施与上面一样：最小权限（只读、范围受限的角色），这样即使代理被劫持也做不了多少坏事。

"只读"必须被强制执行，而不是仅仅承诺。一个只是想运行 SELECT 的服务器是不够的。用一个在数据库层面根本没有写权限的角色来做后盾。双保险。

最小权限优于"用 admin 连接"。很容易想到让 MCP 服务器指向一个超级用户，这样"一切都能工作"。不要这样做。给它完成工作所需的最窄角色。大量有记录的 MCP 事件都可以追溯到过于宽泛的权限。

不是每个 MCP 服务器都值得信任。社区服务器的质量差异很大；一个被广泛分叉的示例向数千个下游项目引入了一个 SQL 注入漏洞。看代码，或者使用你信任的来源提供的托管服务器，并在每个边界验证输入。

这对你意味着什么

如果你只记住一件事：MCP 移动了信任边界。AI 不再是你需要投喂凭证的东西，而变成了通过持有凭证的经纪人请求操作的东西。这对于安全、更快地让非技术队友上手、以及向客户暴露安全的自助数据访问，都是一个更好的形态。

你可以为 Postgres、MySQL 或 SQL Server 自托管一个开源 MCP 服务器，或者使用托管服务。作为托管服务的一个例子，Draxlr 运行着一个 MCP 服务器（docs），你通过 OAuth 连接它是只读设计的，可以列出 schema、运行和保存查询、以及构建仪表板——这是上述模式的一个具体实例。但模式比任何一个实现都重要：经纪人持有连接，AI 什么都不拿。

---

MCP 是一个开放协议，通过结构化的工具接口而非粘贴凭证，将 AI 工具连接到数据库等系统。

经纪人（MCP 服务器）持有数据库连接；AI 永远不会看到你的秘密。

只读角色、基于 OAuth 的可撤销访问、以及行级安全都可以干净地与其组合使用。

通过工具调用实现的 schema 感知能力大幅减少幻觉的表和列。

它不是安全银弹——提示词注入和过于宽泛的权限仍然会伤人。最小权限是你最好的朋友。

---

你已经在将 AI 连接到数据库了吗——自托管 MCP、托管服务器，还是仍在往聊天窗口里粘贴？欢迎在评论区留言；我真的很想了解团队是如何划定这条线的。