1. 为什么要在 KES 上接一个 MCP Server电科金仓 KES 是国产关系型数据库里落地比较多的一个很多团队的业务库、报表库都跑在上面。日常开发里有个很常见的场景你怀疑某条 SQL 慢于是打开数据库客户端翻表结构、看索引、拉执行计划再把结果复制回 AI 对话窗口让它分析。工具之间来回切上下文全靠手动搬一次排查下来光复制粘贴就够烦的。MCP Server 想解决的就是这个断点。它把「查结构、跑 SQL、看执行计划、做健康检查、定位慢查询、模拟索引」这些动作封装成标准工具挂到支持 MCP 的开发工具比如 TRAE、Cursor上。你在对话里说一句「看看 orders 表有哪些字段和索引」工具判断该调哪个能力KES MCP Server 接住请求、做参数校验和访问控制再连到 KES 执行把结果回给模型继续分析。关键点在于模型不能绕过 Server 直连数据库。能调哪些工具、能执行哪类 SQL、能看哪些对象同时受 Server 的访问模式和数据库账号权限两层约束。对 DBA 和开发来说这比「把库账号直接塞给 AI」要可控得多。这篇就按本地 Stdio 的方式把配置骨架和连通性验证走一遍让你在本地完成从配置到调用的闭环。2. 前置准备KES 实例、Python 与 MCP 客户端动手前先把三样东西备齐缺一个后面都会卡住。第一是数据库侧。需要 KES V8R6 及以上版本并且你手上有一个能连的实例地址、端口、库名和账号。强烈建议单独建一个 AI 专用账号只给必要的读权限别拿业务主账号去接。后面 Restricted 模式配合最小权限账号是这套方案安全性的核心。第二是运行环境。KES MCP Server 依赖 Python 3.12 到 3.13版本别乱来低版本可能装不上依赖。包管理用 uv 会比较顺没有的话先装一个。第三是 MCP 客户端。TRAE、Cursor 这类支持 MCP 的开发工具都行本地开发用 Stdio 传输客户端会自动拉起服务进程不用你手动常驻运行。如果你还想用索引假设分析需要数据库侧装sys_hypo扩展想做慢查询和负载分析需要sys_stat_statements扩展。这两个不是必须的但装了之后能力清单里的「索引方案分析」和「慢查询定位」才完整。扩展的安装方式按 KES 官方文档来这里不展开。3. 拉代码、装依赖与 MCP 配置骨架先把项目拉下来并安装依赖。命令很直接# 1. 获取代码 git clone https://gitee.com/king-db/kingbase-mcp cd kingbase-mcp # 2. 安装依赖 uv pip install .装完之后核心工作是在 MCP 客户端里写配置。配置一般分三块数据库连接参数、启动命令、访问模式。下面是一个 Stdio 方式的配置骨架字段名以你客户端实际要求为准但结构基本一致{ mcpServers: { kingbase-kes: { command: uv, args: [ run, kingbase-mcp, --access-mode, restricted ], env: { KES_HOST: 127.0.0.1, KES_PORT: 54321, KES_DATABASE: testdb, KES_USER: ai_readonly, KES_PASSWORD: your_password } } } }几个参数值得单独说。--access-mode restricted是受限模式内置 SQL 类型白名单加严格访问控制从源头拦掉高风险写入和修改操作生产或演示环境建议默认用它。另一个值是unrestricted放开完整数据库操作权限适合需要灵活性的测试环境但别拿它接生产库。KES_USER这里填的就是前面说的 AI 专用最小权限账号。Restricted 模式负责拦 SQL 类型账号权限负责拦对象范围两层叠加才稳。密码别硬编码进会提交到仓库的文件里用环境变量或客户端自带的密钥管理。配置保存后重启客户端Stdio 方式下客户端会自动启动服务进程你不需要单独开一个终端跑uv run kingbase-mcp。4. 验证连通性从看表结构到模拟索引配置写完不代表通了得实际发几个请求验证。我一般按「先读结构、再跑查询、最后做分析」的顺序来每一步都能确认一层链路。第一步验证结构探索。在对话里输入查看 orders 表的结构包括字段、约束和索引。如果 Server 正常连上 KES会返回当前实例里 orders 表的字段列表、约束和已有索引。这一步通了说明连接参数、账号权限、传输链路都没问题。如果返回空或者报连接错误先看第 5 节的排查。第二步验证 SQL 执行与执行计划。拿一条真实的目标 SQL 试SELECT * FROM orders WHERE user_id 123 AND status pending;在对话里说「分析这条 SQL 的执行计划」。Server 会把它送到 KES 真实执行并取回执行计划返回里能看到扫描方式、过滤条件、索引使用情况。如果显示全表扫描、现有索引没生效就进入下一步。第三步验证索引假设分析。这一步依赖sys_hypo扩展模拟在 user_id 和 status 字段上增加联合索引后的执行计划。Server 通过假设索引重新生成执行计划对比前后变化全程不创建物理索引没有额外存储和维护成本。返回结果会展示扫描方式和执行代价的差异。如果模拟结果明显改善再由开发或 DBA 结合查询频率、写入压力、存储成本决定要不要真正建索引。整个流程——看表结构、分析执行计划、验证索引效果——都在同一个开发环境里闭环不用再跨工具搬上下文。这也是这套方案最实际的价值。5. 本篇常见错排查配置和验证过程中几个坑出现频率比较高提前说一下。连不上数据库先分清楚是网络问题还是参数问题。检查KES_HOST、KES_PORT是否可达账号密码是否正确库名是否存在。Stdio 模式下服务由客户端拉起如果客户端日志里看不到服务启动记录多半是command或args写错了比如 uv 不在 PATH 里。Python 版本不对会直接导致依赖装不上。确认python --version在 3.12 到 3.13 之间用 uv 管理虚拟环境能省不少事。Restricted 模式下某些 SQL 被拒绝这是预期行为不是 bug。受限模式有 SQL 类型白名单写入和修改类操作会被拦。如果你确实需要放开切到 unrestricted但务必确认当前连的不是生产库。索引假设分析报错通常是sys_hypo扩展没装。慢查询和负载分析报错检查sys_stat_statements。这两个扩展不装不影响基础的结构探索和 SQL 查询但对应的高级能力用不了。返回结果为空但没报错检查账号权限。最小权限账号如果连目标 schema 的读权限都没有结构探索会返回空。给 AI 账号补上必要的读权限即可别图省事直接上高权限账号。6. 把 AI 接入 KES 的下一步本地跑通之后接下来看你的使用场景分流。如果你主要是在排障和接入阶段需要反复调连接参数、验证权限建议先把 API Keys 和接入文档过一遍把账号和密钥管理理顺地址在 https://taotoken.net/api 密钥在控制台生成文档里有完整的参数说明。如果你更多是验证模型对 SQL 的理解能力、对比不同模型分析执行计划的效果可以直接用模型对话功能快速试不用每次都走完整配置。如果你是长期做编码、想让 AI 在 Agent 流程里持续操作数据库那更适合走 Coding Plan把调用配额和模型选择固定下来避免每次临时配。回到 KES 本身这套 MCP Server 的定位很清楚它是开发工具和数据库之间的关卡模型不能绕过它直连。你把它当成一个受控的数据库访问代理来用配合 Restricted 模式和最小权限账号就能在享受 AI 分析能力的同时把误操作面压到最小。真正落地时索引要不要建、慢 SQL 怎么改最终还是由人拍板AI 负责把信息摆到你面前。