让 AI 直接操控数据库：国产数据库 MCP Server 从入门到实战
目录
引言
想象一下这样的开发场景：你正在 TRAE 或 Cursor 中编写业务代码，突然需要确认某张表的字段结构，或者排查一条慢 SQL。按照传统流程，你需要切换到数据库客户端、找到对应表、查看建表语句、复制到对话窗口请 AI 分析——整个过程割裂而低效。
现在，一切都可以在开发工具内部完成。
直接对 AI 助手说：
- "帮我看看 orders 表有哪些字段和索引。"
- "分析一下这条 SQL 为什么慢。"
- "如果增加联合索引，执行计划会不会改变？"
AI 会直接连接数据库并返回真实结果。
近日，电科金仓在 Gitee 正式开源了 KES MCP Server，将上述体验变为现实。本次发布包含 9 个标准工具，覆盖数据库结构探索、SQL 查询、执行计划分析、健康检查、慢查询定位和索引优化等常见场景。
一、背景：为什么需要 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 工具，由大模型进一步整理和分析
关键设计原则：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 查询和管理操作的数据库引擎 |
2.3 三种传输方式
为适应不同部署场景，KES MCP Server 支持三种传输方式：
|
传输方式 |
适用场景 |
特点 |
|
Stdio |
本地开发 |
标准输入输出通信，无需开放端口，最简洁安全 |
|
SSE |
远程访问 |
Server-Sent Events，适合跨网络调用 |
|
Streamable HTTP |
集中部署 |
配合 HTTPS 和反向代理，适合团队共享或生产环境 |
推荐：个人本地开发首选 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 数据库，精准可靠，无需提前把建表语句复制到对话窗口。
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';
这条查询为什么走了全表扫描？有没有可用的索引？
3.3 数据库健康检查
面向运维场景，通过自然语言一键发起全面健康检查。
检查项包括：
- 索引膨胀检测
- 活跃连接数
- Vacuum 状态（死元组比例）
- 序列溢出风险
- 复制延迟
- 缓存命中率
- 约束完整性
示例指令：
检查一下数据库健康状况。
找出最近总耗时最高的 5 条 SQL。
查看当前有哪些长时间未提交的事务。3.4 索引优化分析
这是 KES MCP Server 最具特色的能力之一：假设索引（Hypothetical Index）分析。
配合 sys_hypo 扩展，可以在不创建真实索引的情况下，模拟新增索引后的执行计划变化。这意味着你可以：
- 提出索引方案猜想
- 验证执行计划是否改善
- 评估代价变化
- 结合查询频率、写入压力和存储成本，决定是否实施
示例指令：
如果在 user_id 和 status 字段上增加联合索引，执行计划会有什么变化？
模拟在 orders 表的 created_at 字段上创建索引后的查询效果。
对比三个候选索引方案，哪个对这条慢查询的优化效果最好？整个过程不会实际创建物理索引，零存储成本、零维护开销、零性能影响。
四、安装与配置：手把手教程
4.1 环境要求
|
组件 |
要求 |
|
KES 数据库 |
V8R6 及以上版本 |
|
Python |
3.12 ~ 3.13 |
|
开发工具 |
TRAE、Cursor 或其他支持 MCP 的客户端 |
|
可选扩展 |
（索引分析）、 （慢查询分析） |
4.2 获取项目代码
git clone https://gitee.com/king-db/kingbase-mcp
cd kingbase-mcp4.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"
}
}
}
}
关键配置参数说明：
|
参数 |
说明 |
备注 |
|
|
或 |
生产环境务必使用 |
|
|
数据库主机地址 |
本地开发填 |
|
|
数据库端口 |
KES 默认端口 |
|
|
数据库用户名 |
建议使用专用只读账户 |
|
|
数据库密码 |
也可通过环境变量或密钥管理工具注入 |
|
|
目标数据库名 |
指定要连接的数据库 |
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 的组合查询条件。
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.00 |
0.29 |
|
总代价 |
12500.00 |
8.50 |
|
代价改善 |
- |
降低 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 协议背景、架构详解、完整安装配置教程和多场景实战示例。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
2
0- 0
已为社区贡献4条内容
所有评论(0)