原文《让AI直接操作数据库，电科金仓KES的MCP实践来了》（金仓数据库，2026-07-13）改写版。保留全部技术事实，去掉宣传腔，按工程师阅读习惯重排。
背景：为什么需要它
过去排查一条慢 SQL，标准动作是：在开发工具里写问题 → 切到数据库客户端查表结构 / 索引 → 复制执行计划 → 回到对话窗口贴给大模型分析。工具之间来回倒腾，上下文还要手动搬运。
电科金仓（Kingbase）近日在 Gitee 开源了 KES MCP Server ，把上述分散操作直接接入 TRAE、Cursor 等支持 MCP 的开发工具。它封装了 9 个标准工具，覆盖结构探索、SQL 查询、执行计划分析、健康检查、慢查询定位与索引优化等常见场景。
text
"帮我看看 orders 表有哪些字段和索引。"
"分析一下这条 SQL 为什么慢。"
"如果增加联合索引，执行计划会不会改变？"现在这些话可以直接在开发工具里说，由 KES 真正去执行。
KES MCP Server 是什么
它位于 开发工具 与 KES 数据库 之间，是模型访问数据库的必经关卡。
交互流程：
- 用户提问，开发工具判断该调用哪个工具；
- KES MCP Server 接收请求，做参数检查与访问控制；
- 连接 KES 执行操作，取回结果；
- 开发工具继续整理、分析。
关键点：模型不能绕过 Server 直连数据库。能调哪些工具、执行哪些 SQL、看哪些对象，同时受 Server 访问模式与数据库账号权限约束。
分层架构（5 层）
从上到下：
| 层 | 职责 |
|---|---|
| AI 客户端层 | TRAE / Cursor 等 MCP 宿主 |
| 传输层 | Stdio / SSE / Streamable HTTP |
| 核心服务与安全层 | 参数校验、访问控制、模式管理 |
| 分析能力层 | 执行计划、慢查询、假设索引等分析 |
| KES 数据库层 | 实际的数据存储与计算 |
三种传输方式
| 方式 | 适用场景 |
|---|---|
| Stdio | 本地开发，不开端口，客户端自动拉起 |
| SSE | 远程访问 |
| Streamable HTTP | 配合 HTTPS / 反向代理 / 网络隔离做集中部署 |
本地开发用 Stdio；团队共享或跨环境用 Streamable HTTP。
安全模型：两种访问模式
数据库是核心基础设施，AI 操作必须可控。KES MCP Server 提供两种模式，可自由切换：
- Restricted（受限，推荐生产/演示）
- 内置 SQL 类型白名单 + 严格访问控制策略；
- 从源头拦截高风险写入与修改操作；
- 建议配置 AI 专用最小权限账户，进一步降低误操作面。
- Unrestricted（开放）
- 放开完整数据库操作权限，支持复杂管理与开发指令；
- 适合需要灵活性的测试环境。
实践建议：默认跑 Restricted，给 AI 一个只读/最小权限的库账号。
能力清单：四类标准工具
1. 查看数据库结构
查看 Schema、表、视图、序列，以及字段、约束、索引等对象详情。信息直接来自当前 KES 实例，无需手动粘贴建表语句。
text
"列出全部或指定 Schema 下的表、视图、序列或扩展。"
"查看 orders 表的字段、约束、索引等对象详情。"2. 执行查询与分析 SQL
按业务需求生成并执行查询，同时可查看 SQL 在 KES 中的真实执行计划。
text
"查询本月销售额排名前 5 的商品。"
"分析这条 SQL 的执行计划。"模型基于返回的扫描方式、过滤条件、索引使用情况，定位性能问题。
3. 检查数据库运行状态
一句指令发起健康检查，覆盖索引、连接、Vacuum、序列、复制、缓存、约束等维度；也能拉取高耗时查询。
text
"检查一下数据库健康状况。"
"找出最近总耗时最高的 5 条 SQL。"4. 分析索引方案
针对指定 SQL 或历史负载分析索引。配合 sys_hypo 扩展，可在不创建真实索引的情况下模拟新增索引后的执行计划，先评估有效性再决定是否落地。
text
"如果在 user_id 和 status 字段上增加联合索引，执行计划会有什么变化？"安装与配置
前置要求
- KES V8R6 及以上
- Python 3.12 ~ 3.13
- TRAE / Cursor 等支持 MCP 的开发工具
步骤
bash
# 1. 获取代码
git clone https://gitee.com/king-db/kingbase-mcp
# 2. 安装依赖
uv pip install .随后在 MCP 客户端中配置：数据库连接、启动命令、访问模式。生产/演示环境建议启用 Restricted：
bash
uv run kingbase-mcp --access-mode restricted本地 Stdio 方式下，通常由客户端自动启动服务，无需提前单独运行。
扩展依赖
- 索引假设分析 → 需 sys_hypo 扩展
- 慢查询与负载分析 → 需 sys_stat_statements 扩展
完整配置参数见项目 README。
实战：在开发工具里完成一次 SQL 优化
目标 SQL：
sql
SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';① 看结构
"查看 orders 表的结构，包括字段、约束和索引。"
Server 返回当前表结构与索引，判断是否已有可用索引。
② 分析执行计划
"分析这条 SQL 的执行计划。"
若结果显示全表扫描、现有索引未生效，则进入下一步验证。
③ 验证新索引方案
"模拟增加 user_id 和 status 联合索引后的执行计划。"
Server 通过假设索引重新生成执行计划，并对比前后变化。全程不创建物理索引，无额外存储与维护成本。 返回结果会展示扫描方式与执行代价。
④ 决策 若模拟结果明显改善，再由开发/DBA 结合查询频率、写入压力、存储成本决定是否真正建索引。
整个流程------看表结构 → 分析执行计划 → 验证索引效果------在同一个开发环境内闭环，不再跨工具搬运上下文。
获取与参与
- 立即体验：项目地址见文末「阅读原文」→ gitee.com/king-db/kin...
- 主题征文：可将使用体验整理成文投稿，详见 KES MCP Server 主题征文活动。
供稿：数据库产品研发中心｜编辑：格格｜审核：日尧｜部分图片由 AI 辅助生成