从连接到安全落地：KES MCP Server 工程化实践的全记录

文章目录

- 一、先搞清楚它是what
- [二、配置使用：把 Agent 接到 KES 上](#二、配置使用：把 Agent 接到 KES 上)
- - [2.1 环境清单](#2.1 环境清单)
  - [2.2 建一个最小权限的 AI 专用账号](#2.2 建一个最小权限的 AI 专用账号)
  - [2.3 拉代码、与装依赖](#2.3 拉代码、与装依赖)
  - [2.4 选传输方式](#2.4 选传输方式)
  - [2.5 在 Cursor 里配客户端](#2.5 在 Cursor 里配客户端)
- 三、能力应用：用自然语言把活干完
- - [3.1 结构查询：不用再背表结构](#3.1 结构查询：不用再背表结构)
  - [3.2 SQL 生成与执行计划分析](#3.2 SQL 生成与执行计划分析)
  - [3.3 数据查询：自然语言转 SQL](#3.3 数据查询：自然语言转 SQL)
  - [3.4 运维辅助：健康检查和慢查询](#3.4 运维辅助：健康检查和慢查询)
  - [3.5 索引优化](#3.5 索引优化)
- 四、服务端编程开发：存储过程、函数、触发器
- - [4.1 存储过程：批量写入的正确姿势](#4.1 存储过程：批量写入的正确姿势)
  - [4.2 调试：用 MCP 定位存储过程里的慢语句](#4.2 调试：用 MCP 定位存储过程里的慢语句)
  - [4.3 函数开发：开启编译执行](#4.3 函数开发：开启编译执行)
  - [4.4 触发器：别让它在高频写入路径上拖后腿](#4.4 触发器：别让它在高频写入路径上拖后腿)
- 五、场景开发：我们搭三个助手
- - [5.1 数据库开发助手](#5.1 数据库开发助手)
  - [5.2 数据分析助手](#5.2 数据分析助手)
  - [5.3 智能运维助手](#5.3 智能运维助手)
- 六、踩坑清单列表

我做数据库开发久了，经历过这种反复横跳：在 IDE 里写 SQL，觉得慢了，切到数据库客户端看表结构，再切回来看执行计划，截图、复制、粘贴，最后把一堆信息丢给AI大模型让它帮忙分析一下。十几分钟就这么过去了。
电科金仓在 Gitee 上开源了 KES MCP Server，把这套碎片化操作收集到一个对话窗口里。本篇文章是我们从环境准备、连接配置，然后一直到存储过程调优、智能运维助手搭建的完整工程化记录。主要的过程是怎么从连通数据库，到安全、稳稳滴把数据库任务做掉了。

一、先搞清楚它是what

KES MCP Server 是夹在 AI 开发工具:Cursor、TRAE、Claude Desktop 这类支持 MCP 协议的客户端,以及金仓 KingbaseES 数据库之间的中间层，一身兼两个角色：比喻成翻译官和守门员。

用户可以在对话框里说一句"看看 orders 表有哪些索引？"，AI 判断该调哪个工具，MCP Server 接到请求后做参数校验和访问控制，然后再连上 KES 执行，结果回传给 AI 做二次解读。全程 AI 其实没法绕过 Server 直接摸数据库。能调哪些工具、执行什么 SQL、看哪些对象，不仅受到 Server 访问模式约束，也受数据库账号权限限制。它内置了 10 个标准化d工具，覆盖四类比较高频次的场景：

类别	工具	干什么？
结构探索	`list_schemas` / `list_objects` / `get_object_details`	列 schema、表、视图、序列，看列/约束/索引
查询计划	`execute_sql` / `explain_query`	执行 SQL、EXPLAIN，支持假设索引
运维诊断	`analyze_db_health` / `get_top_queries` / `analyze_db_config`	7 维健康检查、Top N 慢查询、参数配置分析
索引优化	`analyze_workload_indexes` / `analyze_query_indexes`	基于负载或指定 SQL 推荐索引

它是基于开源的 postgres-mcp 二次开发，MIT 协议。if你也在用 PostgreSQL 系的库，思路其实可以完全能迁移过去的时刻。

二、配置使用：把 Agent 接到 KES 上

2.1 环境清单

我们动手前，先把家底了解清楚一点吧：

组件	要求	说明
KingbaseES	V8R6 及以上	暂不支持容器快速部署，需手动装
Python	3.12 ~ 3.13	ksycopg2 驱动最高支持到 3.13
平台	Linux x86_64/Aarch64、Windows	Mac 和 Alpine 没有官方 ksycopg2 驱动
客户端	Cursor / TRAE / Claude Desktop	要支持 MCP Client
可选扩展	sys_hypo、sys_stat_statements	不装会损失假设索引和慢查询分析能力

2.2 建一个最小权限的 AI 专用账号

生产环境可不能拿 DBA 账号给 MCP 用。先用 system 账号连上库，建一个只读的专用账号：

这一步是纵深防御的第一道闸。就算 MCP 的受限模式被绕过，账号本身也只有 SELECT 权限，删不掉数据。把两个可选扩展装上，不然后面的索引和慢查询都会报"扩展不存在"：

2.3 拉代码、与装依赖

bash 复制代码

[kingbase@kes-server ~]$ cd kingbase-mcp

我们可以用uv 管依赖：

这里有两个我亲自踩过的坑，提前也给大家排了。

坑1，PyPI 下载超时。ruff、pyright 这些 dev 依赖走官方源容易断流。换清华镜像一劳永逸：

bash 复制代码

uv pip install -i https://pypi.tuna.tsinghua.edu.cn/simple .

坑2，MCP SDK 版本飘了。仓库声明的是 mcp[cli]>=1.25.0,<2，但if你手动装依赖没钉版本，uv 可能给你拉到 MCP 2.0（2026 年 7 月底正式发布），启动直接报 ImportError。显式钉一下就行：

bash 复制代码

uv pip install "mcp<2"

2.4 选传输方式

Server 提供三种传输，按部署形态选1个：

传输的方式	路径	适合谁
Stdio	本地子进程，不开端口	本机开发，配置最省事，客户端自动拉起
SSE	`/sse`	早期远程方案，HTTP 长连接
Streamable HTTP	`/mcp`	企业集中部署，支持反向代理 + HTTPS + 网络隔离，官方推荐

我本机调试用 Stdio，团队共享那台库上跑 Streamable HTTP。

2.5 在 Cursor 里配客户端

Stdio 模式下不用手动启动 Server，客户端会自动拉起。找到配置的文件（Windows 是 %USERPROFILE%\.cursor\mcp.json，macOS 是 ~/.cursor/mcp.json），写入：

json 复制代码

{
  "mcpServers": {
    "kingbase-mcp": {
      "command": "uv",
      "args": [
        "--directory",
        "/home/kingbase/kingbase-mcp",
        "run",
        "kingbase-mcp",
        "--access-mode",
        "restricted"
      ],
      "env": {
        "DATABASE_URI": "kingbase://ai_mcp:K1ngbase@2026#Mcp@127.0.0.1:54321/testdb"
      }
    }
  }
}

if你是 TRAE，在项目根目录下建一个 .trae/mcp.json，结构略不同，照着填即可。

配置存盘后完全退出 Cursor 再打开，MCP 面板里能看到 kingbase-mcp 已加载，10 个工具全部可见，就说明接通了。

验证一下，在对话框里敲呢：

列出当前数据库的所有 schema

if AI 返回了 public、sys_catalog、information_schema 这些，连通成功。

三、能力应用：用自然语言把活干完

接通只是第一步。下面这些场景才是日常用得上的，我们可以按"结构查询 → SQL 生成分析 → 数据查询 → 运维辅助"的顺序讲。

3.1 结构查询：不用再背表结构

老办法是 \d orders 或者翻系统表。现在可以直接问：

查看 public schema 下 orders 表的字段、约束和现有索引

AI 可以调 get_object_details，返回结构化的列定义、主键、外键、索引清单。我在排查一个订单查询时，第一句问这个，确认 user_id 和 status 上到底有没有联合索引?

返回结果长这样：

复制代码

orders 表结构
├─ 字段
│  ├─ id           BIGINT, 主键
│  ├─ user_id      BIGINT, NOT NULL
│  ├─ status       VARCHAR(20), 默认 'pending'
│  ├─ amount       NUMERIC(12,2)
│  └─ created_at   TIMESTAMP
├─ 约束
│  ├─ 主键: orders_pkey (id)
│  └─ 外键: fk_orders_user → users(id)
└─ 索引
   └─ orders_pkey (id)  ← 只有主键索引，没有 (user_id, status)

能看出，按 user_id 和 status 过滤的查询会全表扫描。

3.2 SQL 生成与执行计划分析

把那条慢查询丢给 AI：

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

AI 调 explain_query，返回的真实执行计划会显示 Seq Scan，代价不低。好在 AI 其实不止把计划甩给你，还会解读："当前走了全表扫描，因为 user_id 上没有可用的索引，estimated rows 远大于实际，统计信息可能过期。"

这种"给结果 + 给判断"的输出，比单纯 EXPLAIN 一行行密密麻麻的文本好读太多啦。

3.3 数据查询：自然语言转 SQL

查询本月销售额前 5 的商品，包含商品名和销售额

AI 会先用 get_object_details 摸清表结构，生成一条 JOIN 查询，再用 execute_sql 在 restricted 模式下跑出来。整个过程你不用写一行 SQL。

受限模式下 execute_sql 走的是 AST 白名单，只放行 SELECT、EXPLAIN、SHOW、VACUUM/ANALYZE 这类只读语句。哪怕 AI 生成了一条 DELETE FROM orders，也会被直接拦截，报 Error validating query。

3.4 运维辅助：健康检查和慢查询

这是我用得最多的能力。一句"检查一下数据库健康状况"，AI 可以调 analyze_db_health，跑 7 项检查：索引、连接利用率、vacuum 回卷风险、序列耗尽、复制延迟、缓存命中率、约束有效性。

一次真实输出里，大部分正常，但有1项亮了黄灯了：

复制代码

⚠️ Vacuum 回绕预警
   对象: sys_catalog._kingbase_loginfo
   剩余事务数: -9,999,999（阈值 10,000,000）
   建议: VACUUM sys_catalog._kingbase_loginfo;

慢查询排查同样省事：

找出最近总耗时最高的 5 条查询

AI 调 get_top_queries，基于 sys_stat_statements 返回 Top N。我那次发现前两条慢查询吃掉了 83.5% 的总耗时。一条 JOIN ... ON id != id 跑了 7 次扫了 460 万行，另一条 CROSS JOIN 跑了 80 次。这种问题，过去的时刻要自己写一大堆的 sys_stat_statements 的查询语句去捞，现在一句话的事，就可以完完全全的搞定啦啦。

3.5 索引优化

这部分是最没想到的办法，配合 sys_hypo 扩展。

在 orders 表上加联合索引，对比执行计划变化

AI 可以调 explain_query 并传入 hypothetical_indexes 参数，返回对比：

复制代码

优化前                          优化后
Seq Scan on orders             Index Scan using <hypo> on orders
  Cost: 34910.76                 Cost: 8.32
  Rows: 1 (actual 1)             Rows: 1 (actual 1)

代价从 34910 掉到 8.32，感觉是效果比较明显。确认有效后再让 DBA 手动 CREATE INDEX，避免了盲目建索引浪费存储、拖慢写入。

基于历史负载的推荐更猛。analyze_workload_indexes 会分析 sys_stat_statements 里的查询负载，用 DTA算法推荐索引。我在一台测试库上跑过，它推荐在 products(price) 上建索引，预估总成本从 6780 万降到 669 万，10 倍提升。执行计划里那条全表扫描的 Seq Scan 直接变成了 Index Scan。

四、服务端编程开发：存储过程、函数、触发器

KES 兼容 Oracle，PL/pgSQL是它的强项。这一块 MCP Server 帮不上直接忙，它不能帮你写存储过程逻辑，但在调试和性能定位上价值很大。

4.1 存储过程：批量写入的正确姿势

先看一个典型的批量插入存储过程。错误的写法是循环里逐条 INSERT，每条都走一次网络往返：

sql 复制代码

-- 反面教材：逐条插入，很慢啊
CREATE OR REPLACE PROCEDURE bad_batch_insert(p_count INT) AS $$
DECLARE i INT;
BEGIN
  FOR i IN 1..p_count LOOP
    INSERT INTO logs(msg) VALUES ('row ' || i);
  END LOOP;
END;
$$ LANGUAGE plpgsql;

正确做法是用批量或 INSERT ... SELECT 一次性写入。

4.2 调试：用 MCP 定位存储过程里的慢语句

存储过程跑得慢，最大的痛点是不知道哪一行 SQL 拖后腿。传统办法是装 plsql_plprofiler 做行级耗时分析。现在多了一条路：把存储过程里的关键 SQL 摘出来，丢给 MCP 做执行计划分析。

我有一次排查一个工资计算存储过程，怀疑里面某条 SELECT 慢。直接问 AI：

分析这条 SQL 的执行计划：SELECT e.basic_salary + p.bonus FROM employees e, performance p WHERE e.id = p.id AND e.id = 5

AI 可以调 explain_query 返回计划，发现是笛卡尔积式连接导致扫描行数爆炸。把存储过程里的写法改成显式 JOIN 后，耗时从 2 秒降到 80 毫秒。

另一个调试利器是 auto_explain。它能把存储过程内部每条 SQL 的执行计划自动记到日志里。某次一个存储过程卡住、CPU 飙到 100%，auto_explain 日志显示卡在一条 INSERT INTO ... SELECT，优化器选了 Nested Loop Left Join 连了两张大表。临时关掉 nestloop 验证：

sql 复制代码

SET enable_nestloop = off;

果然改用 Hash Join 后可以快快地跑完。这种"先用 MCP 看计划、再用 auto_explain 定位、最后调优化器开关"的组合拳，比过去的时刻纯靠经验猜效率高太多。

4.3 函数开发：开启编译执行

KES 的 PL/pgSQL 支持编译执行，对计算密集型函数提高速度明显。原理是把存储过程编译成动态库存进系统表，运行时不再解释执行。

sql 复制代码

-- 一个累加函数
CREATE OR REPLACE FUNCTION caln(n INTEGER) RETURNS BIGINT AS $$
DECLARE v_total BIGINT;
BEGIN
  v_total := 0;
  FOR i IN 1..n LOOP
    v_total := v_total + i;
  END LOOP;
  RETURN v_total;
END;
$$ LANGUAGE plpgsql;

先看解释执行的耗时：

sql 复制代码

test=# \timing on
Timing is on.
test=# SELECT caln(10000000);
       caln
--------------------
 50000005000000

时间：1954.474 ms

开启编译执行：

sql 复制代码

test=# SET plpgsql.enable_native_code = on;
SET
时间：0.240 ms

test=# SELECT caln(10000000);
       caln
--------------------
 50000005000000

时间：312.108 ms

从 1954ms 降到 312ms，6 倍提升。我们可以直接在 MCP 对话里让 AI 帮你对比、记录，省去手动整理的功夫。

4.4 触发器：别让它在高频写入路径上拖后腿

触发器方便，但用不好就是性能杀手。一个经验：触发器里的逻辑越轻越好，尤其在高频 INSERT/UPDATE 的表上。if一个触发器里还要去查别的表，基本等于每次写入多一次查询。

调试触发器时，我习惯用 MCP 把触发器调用的函数里的 SQL 单独拎出来做执行计划分析，确认它没有走全表扫描。这比在触发器里埋 RAISE NOTICE 打日志要干净。

五、场景开发：我们搭三个助手

把上面的能力组合起来，就能搭出真正能用的智能体应用。我搭了三个，挑实现过程和复盘讲。

5.1 数据库开发助手

目标让程序开发人用自然语言完成建表设计、SQL 编写、执行计划调优的闭环。

做法是以 Cursor + KES MCP Server 为底座，restricted 模式连开发库。程序开发人描述需求，AI 先用结构探索工具摸清现有 schema，生成 DDL，再生成查询 SQL 并跑执行计划验证。一个新人接手一个老项目，过去的时刻光搞清楚 200 多张表的关联就需要两天的实际，现在半天就能对着 AI 问出"订单状态流转涉及哪几张表、外键怎么连"？。不过有个边界还是要说清楚：restricted 模式下 AI 没法直接建表，生成的 DDL 要人复制出来，手动跑一跑。DDL 这种结构性变更本就该有人 review一下。但得给团队讲明白，别让他们以为"AI 帮我建好了"。

5.2 数据分析助手

我们目标是让业务人员不写 SQL 也能跑数据。同样 restricted + 只读账号。业务描述"上个月华东区各品类销量对比"，AI 转 SQL、执行、把结果整理成表格或图表描述。运营的同学自己就能拿到数，不再排队等数据开发排期。我们踩过1个坑：大表全量查询把库这个都拖慢了啊。restricted 虽然只读，但没限制返回行数。后来在账号层加了查询超时，并在对话里约束 AI"超过 1 万行的查询先告知用户，用户自己进行确认"。MCP Server 本身有 30 秒超时，但大表 COUNT 也能卡满 30 秒。

5.3 智能运维助手

我们目标是定期巡检加异常预警，把 DBA 从重复劳动摆脱出来。用 Streamable HTTP 模式集中部署一台 MCP Server，然后配一个调度脚本，再定时触发健康检查和慢查询分析，把结果推送到企业微信。核心调度脚本是这样：

bash 复制代码

#!/bin/bash
# 每天早上 8 点跑一次健康巡检
0 8 * * * /home/kingbase/scripts/mcp_health_check.sh

脚本内部调用 MCP 的 HTTP 接口触发 analyze_db_health，把 JSON 结果解析成我们人类可读的报告。上线第一周就找出一个 vacuum 回卷风险和一个复制槽堆积，在都是平时容易漏的隐患。

我们复盘下来：调度脚本要处理好 MCP Server 的可用性，Server 挂了调度不能静默失败，我们觉得得有告警。另外健康检查结果里的"建议操作"不可以无人 review 直接执行，比如 VACUUM 大表可能锁库，还是得走 DBA 审批流程哦。

六、踩坑清单列表

踩坑	现象	解法
PyPI 超时	`uv pip install` 卡死或报 timeout	换清华镜像 `-i https://pypi.tuna.tsinghua.edu.cn/simple`
MCP SDK 2.0 不兼容	启动报 `ImportError`	`uv pip install "mcp<2"` 钉版本
Mac/Alpine 无驱动	`ksycopg2` 装不上	换 Linux/Windows，或用 psycopg2 伪装
libkci.so 找不到	Linux 启动报 `libkci.so: cannot open shared object file`	配 `KSYCOPG2_LIB_PATH` 指向 ksycopg2 目录
客户端识别不到工具	Cursor 重启后 MCP 面板空	检查 `--directory` 用绝对路径，确认 Python 版本 3.12~3.13
慢查询无数据	`get_top_queries` 返回空	`ALTER SYSTEM SET sys_stat_statements.track='all'` 后跑一段负载
假设索引不可用	`explain_query` 报扩展缺失	`CREATE EXTENSION sys_hypo;`