让 AI 直接操控数据库：国产数据库 MCP Server 从入门到实战 - 文章 - 开发者社区

引言

想象一下这样的开发场景：你正在 TRAE 或 Cursor 中编写业务代码，突然需要确认某张表的字段结构，或者排查一条慢 SQL。按照传统流程，你需要切换到数据库客户端、找到对应表、查看建表语句、复制到对话窗口请 AI 分析——整个过程割裂而低效。

现在，一切都可以在开发工具内部完成。

直接对 AI 助手说：

"帮我看看 orders 表有哪些字段和索引。"
"分析一下这条 SQL 为什么慢。"
"如果增加联合索引，执行计划会不会改变？"

AI 会直接连接数据库并返回真实结果。

近日，电科金仓在 Gitee 正式开源了 KES MCP Server，将上述体验变为现实。本次发布包含 9 个标准工具，覆盖数据库结构探索、SQL 查询、执行计划分析、健康检查、慢查询定位和索引优化等常见场景。

picture.image

一、背景：为什么需要 MCP Server？

1.1 传统开发流程的痛点

过去，开发人员在排查数据库问题时，典型的工作流是这样的：

编写代码 → 发现问题 → 打开数据库客户端 → 查询表结构 →
复制建表语句 → 粘贴给 AI 分析 → 再回到数据库查看执行计划 →
手动对比结果 → 回到代码修改

每一步都涉及工具切换和手动复制粘贴，不仅效率低下，还容易出错。当问题涉及多张表、多个索引时，这种割裂感尤为明显。

1.2 MCP 协议是什么？

MCP（Model Context Protocol） 是由 Anthropic 提出的开放协议，旨在为大语言模型提供标准化的外部工具调用接口。简单来说，MCP 定义了一套规范，让 AI 模型能够：

发现（Discovery） ：知道有哪些工具可用
调用（Invocation） ：以标准格式发起工具调用请求
响应（Response） ：接收结构化的返回结果

MCP 采用客户端-服务端架构：

┌──────────────┐       MCP 协议       ┌──────────────┐      数据库协议     ┌──────────┐
│  AI 开发工具  │  ←─────────────────→  │  MCP Server  │  ←────────────────→  │  数据库   │
│ (TRAE/Cursor) │   工具发现/调用/响应    │  (KES MCP)   │   查询/分析/管理     │   (KES)   │
└──────────────┘                       └──────────────┘                    └──────────┘

通过 MCP，AI 不再只能"阅读"你手动粘贴的文本，而是可以直接"操作"真实的数据源——这就是 MCP Server 的核心价值。

二、KES MCP Server 架构解析

2.1 整体架构

KES MCP Server 位于 AI 开发工具和 KES 数据库之间，扮演"安全中间人"的角色。其工作流程如下：

用户提问：开发者在 AI 工具中输入自然语言问题
工具匹配：AI 工具判断需要调用哪个 MCP 工具
请求转发：KES MCP Server 接收请求，完成参数校验和访问控制
执行操作：通过数据库驱动连接 KES 并执行相应操作
结果返回：数据库结果经 MCP Server 格式化后返回给 AI 工具，由大模型进一步整理和分析

picture.image

关键设计原则：AI 工具不能绕过 MCP Server 直接访问数据库。模型能调用哪些工具、执行哪些 SQL、查看哪些对象，同时受 Server 层面的访问模式限制和数据库账号权限的双重约束。

2.2 五层分层架构

KES MCP Server 采用清晰的分层设计，从上到下依次为：

层级	名称	职责
L1	AI 客户端层	TRAE、Cursor 等支持 MCP 的开发工具，负责交互和结果呈现
L2	传输层	支持 Stdio / SSE / Streamable HTTP 三种传输方式
L3	核心服务与安全层	工具注册、参数校验、访问控制、SQL 白名单过滤
L4	分析能力层	执行计划分析、假设索引、慢查询分析、健康检查等
L5	KES 数据库层	实际执行 SQL 查询和管理操作的数据库引擎

picture.image

2.3 三种传输方式

为适应不同部署场景，KES MCP Server 支持三种传输方式：

传输方式	适用场景	特点
Stdio	本地开发	标准输入输出通信，无需开放端口，最简洁安全
SSE	远程访问	Server-Sent Events，适合跨网络调用
Streamable HTTP	集中部署	配合 HTTPS 和反向代理，适合团队共享或生产环境

picture.image

推荐： 个人本地开发首选 Stdio；团队共享或跨环境使用时选择 Streamable HTTP。

2.4 安全机制：双模式访问控制

数据库是企业的核心资产，AI 的介入必须建立在严格的安全基础之上。KES MCP Server 提供两种访问模式：

Restricted 模式（推荐用于生产环境）

SQL 类型白名单：仅允许 SELECT、EXPLAIN 等只读操作
严格访问控制：拦截并拒绝 INSERT、UPDATE、DELETE、DROP、TRUNCATE 等写操作
最小权限原则：建议配合专用的 AI 数据库账户，仅授予必要的最小权限集合
从源头阻断：非法写入或修改行为在 MCP Server 层就被拦截，不会到达数据库

Unrestricted 模式（仅用于测试环境）

完整数据库操作权限：支持所有 SQL 类型
适用场景：开发调试、管理类指令执行
风险提示：务必在隔离的测试环境中使用，并做好数据备份

最佳实践：生产环境务必使用 Restricted 模式 + AI 专用最小权限账户，双重保障数据安全。

三、核心功能详解

KES MCP Server 的 9 个标准工具覆盖四大类能力：

3.1 数据库结构探索

让你在对话窗口直接查看数据库元数据，无需手动查询 information_schema。

支持的操作：

列出所有或指定 Schema 下的表、视图、序列、扩展
查看指定表的字段详情（名称、类型、是否可空、默认值）
查看表的约束信息（主键、外键、唯一约束、检查约束）
查看表的索引信息（索引名、索引类型、包含列）

示例指令：

列出 public schema 下的所有表。
查看 orders 表的字段、约束、索引等对象详情。
显示 user 表上所有索引的详细信息。

返回的信息直接来自当前 KES 数据库，精准可靠，无需提前把建表语句复制到对话窗口。

picture.image

3.2 SQL 查询与执行计划分析

这是日常开发中使用最频繁的能力。

支持的操作：

根据业务需求生成并执行只读查询（Restricted 模式下）
查看 SQL 在 KES 中的实际执行计划（EXPLAIN / EXPLAIN ANALYZE）
分析扫描方式（Seq Scan / Index Scan / Bitmap Scan）
判断过滤条件和索引使用情况

示例指令：

查询本月销售额排名前 5 的商品。
分析这条 SQL 的执行计划：SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';
这条查询为什么走了全表扫描？有没有可用的索引？

picture.image

3.3 数据库健康检查

面向运维场景，通过自然语言一键发起全面健康检查。

检查项包括：

索引膨胀检测
活跃连接数
Vacuum 状态（死元组比例）
序列溢出风险
复制延迟
缓存命中率
约束完整性

示例指令：

检查一下数据库健康状况。
找出最近总耗时最高的 5 条 SQL。
查看当前有哪些长时间未提交的事务。

3.4 索引优化分析

这是 KES MCP Server 最具特色的能力之一：假设索引（Hypothetical Index）分析。

配合 sys_hypo 扩展，可以在不创建真实索引的情况下，模拟新增索引后的执行计划变化。这意味着你可以：

提出索引方案猜想
验证执行计划是否改善
评估代价变化
结合查询频率、写入压力和存储成本，决定是否实施

picture.image

示例指令：

如果在 user_id 和 status 字段上增加联合索引，执行计划会有什么变化？
模拟在 orders 表的 created_at 字段上创建索引后的查询效果。
对比三个候选索引方案，哪个对这条慢查询的优化效果最好？

整个过程不会实际创建物理索引，零存储成本、零维护开销、零性能影响。

四、安装与配置：手把手教程

4.1 环境要求

组件	要求
KES 数据库	V8R6 及以上版本
Python	3.12 ~ 3.13
开发工具	TRAE、Cursor 或其他支持 MCP 的客户端
可选扩展	sys_hypo（索引分析）、sys_stat_statements（慢查询分析）

4.2 获取项目代码

git clone https://gitee.com/king-db/kingbase-mcp
cd kingbase-mcp

4.3 安装依赖

推荐使用 uv（快速的 Python 包管理器）：

# 如果尚未安装 uv
pip install uv

# 安装项目依赖
uv pip install .

也可以使用传统方式：

pip install -r requirements.txt

4.4 配置 MCP 客户端

以 Cursor 为例，在 MCP 配置文件中添加如下配置：

.cursor/mcp.json 或全局 MCP 配置：

{
  "mcpServers": {
    "kes-mcp": {
      "command": "uv",
      "args": [
        "run",
        "kingbase-mcp",
        "--access-mode", "restricted"
      ],
      "env": {
        "KES_HOST": "localhost",
        "KES_PORT": "54321",
        "KES_USER": "ai_readonly",
        "KES_PASSWORD": "your_password",
        "KES_DATABASE": "your_database"
      }
    }
  }
}

picture.image

关键配置参数说明：

参数	说明	备注
--access-mode	restricted 或 unrestricted	生产环境务必使用 restricted
KES_HOST	数据库主机地址	本地开发填 localhost
KES_PORT	数据库端口	KES 默认端口 54321
KES_USER	数据库用户名	建议使用专用只读账户
KES_PASSWORD	数据库密码	也可通过环境变量或密钥管理工具注入
KES_DATABASE	目标数据库名	指定要连接的数据库

picture.image

4.5 验证安装

配置完成后，在 Cursor 或 TRAE 的对话窗口中输入：

列出当前数据库中的所有 Schema。

如果正确返回数据库结构信息，说明配置成功。

4.6 可选扩展安装

索引分析和慢查询分析需要额外的数据库扩展：

-- 在 KES 中执行（需要超级用户权限）
CREATE EXTENSION sys_hypo;              -- 假设索引分析
CREATE EXTENSION sys_stat_statements;   -- 慢查询和负载分析

五、实战演示：在开发工具中完成一次完整的 SQL 优化

下面以一个真实场景为例，展示如何利用 KES MCP Server 在开发工具内完成从"发现问题"到"验证方案"的完整闭环。

场景设定

你正在开发一个电商系统的订单模块，发现以下查询响应缓慢：

SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';

Step 1：查看表结构

在 AI 对话窗口中输入：

查看 orders 表的结构，包括字段、约束和索引。

KES MCP Server 返回类似以下信息：

表名: public.orders
字段:
  - id (bigint, NOT NULL, 主键)
  - user_id (integer, NOT NULL)
  - product_id (integer, NOT NULL)
  - amount (numeric(10,2))
  - status (varchar(20))
  - created_at (timestamp)
  - updated_at (timestamp)

约束:
  - orders_pkey: PRIMARY KEY (id)
  - orders_user_id_fkey: FOREIGN KEY (user_id) REFERENCES users(id)

索引:
  - orders_pkey: BTREE (id)
  - idx_orders_created_at: BTREE (created_at)

Step 2：分析执行计划

分析这条 SQL 的执行计划：SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';

返回的执行计划可能显示：

Seq Scan on orders  (cost=0.00..12500.00 rows=50 width=200)
  Filter: ((user_id = 123) AND (status = 'pending'::text))

这表明当前查询走的是全表扫描，现有索引（idx_orders_created_at）无法覆盖 user_id 和 status 的组合查询条件。

picture.image

Step 3：验证索引优化方案

如果在 user_id 和 status 字段上创建联合索引，执行计划会有什么变化？

KES MCP Server 通过 sys_hypo 生成假设索引，返回优化后的执行计划：

Index Scan using hypothetical_idx_user_status on orders  (cost=0.29..8.50 rows=50 width=200)
  Index Cond: ((user_id = 123) AND (status = 'pending'::text))

对比结果：

指标	优化前	优化后
扫描方式	Seq Scan（全表扫描）	Index Scan（索引扫描）
启动代价	0	0.29
总代价	12500	8.5
代价改善	-	降低 99.93%

Step 4：决策与实施

模拟结果显示优化效果显著，接下来结合实际情况做出决策：

确认该查询的执行频率
评估 user_id + status 联合索引对写入性能的影响
考虑存储成本

确认方案可行后，由 DBA 执行实际的索引创建：

CREATE INDEX idx_orders_user_status ON orders(user_id, status);

六、常见使用场景速览

场景一：新人接手项目快速了解数据库

列出 public schema 下所有表及其注释。
依次查看每张表的字段和索引。
找出哪些表之间有关联关系。

场景二：日常 SQL 调优

找出最近 1 小时总耗时最高的 10 条 SQL。
逐条分析执行计划，标注全表扫描的查询。
针对全表扫描的查询，模拟添加索引后的效果。

场景三：上线前数据库检查

检查数据库健康状况。
查看是否存在索引膨胀。
检查复制延迟是否在可接受范围。
确认序列没有溢出风险。

场景四：代码 Review 中的 SQL 审查

分析以下 SQL 的执行计划，是否存在性能隐患。
这个查询条件能否命中现有索引？
如果不行，建议一个索引方案并模拟验证。

七、最佳实践建议

始终使用 Restricted 模式连接生产数据库——AI 的创造力有时会超出预期，多一层保护永远不过分。
为 AI 创建专用的最小权限数据库账户——只授予 SELECT 权限和必要的扩展使用权限，杜绝误操作风险。
假设索引验证后再实施——先通过 sys_hypo 模拟，确认优化效果后再创建真实索引，避免无效索引的维护开销。
敏感信息使用 环境变量——不要在配置文件中硬编码数据库密码，使用环境变量或密钥管理服务注入。
定期审计 AI 的查询日志——了解 AI 生成了哪些查询，及时发现异常访问模式。
本地开发用 Stdio，团队协作用 Streamable HTTP——合理选择传输方式，平衡便捷性和安全性。

八、总结

KES MCP Server 将数据库探索、SQL 分析、健康检查和索引优化等操作无缝融入 AI 开发工具，让开发者告别在多个工具之间来回切换的低效模式。

从查看表结构到分析执行计划，再到验证索引效果——原本需要跨工具、跨窗口完成的流程，现在可以在同一个对话中一气呵成。

立即体验：访问 Gitee 仓库 king-db/kingbase-mcp 获取项目源码和详细文档。

本文基于电科金仓官方发布内容改写、扩充，补充了 MCP 协议背景、架构详解、完整安装配置教程和多场景实战示例。