不用再切窗口查数据库了！KES MCP Server发布，AI帮你一条指令搞定SQL优化
在日常开发中，你是否经常遇到这样的场景——排查一条SQL的性能问题，需要在IDE和数据库管理工具之间反复横跳：先切到Navicat看表结构，再切到DBeaver查索引，然后把执行计划复制出来，贴给AI分析……整个过程割裂又低效。
现在，这个痛点有了新的解法。
近日，电科金仓正式在Gitee开源了KES MCP Server，将数据库的常用操作封装为9个标准化的MCP工具，覆盖了从结构探索、SQL执行、执行计划分析，到健康巡检、慢查询定位、索引优化建议等高频场景。开发者可以直接在TRAE、Cursor等支持MCP协议的IDE中，通过自然语言让AI助手与KES数据库交互，无需切换窗口。
换句话说，过去你需要手动在数据库客户端里执行的那些查询——查表结构、看索引、跑EXPLAIN、找慢SQL，现在只需要在IDE的对话框里用自然语言说一句话，背后的MCP Server就会帮你完成，并把结果带回AI的上下文中，由大模型进一步解读和给出建议。
理解KES MCP Server：它充当了AI与数据库之间的"翻译官"
KES MCP Server在整个技术栈中的角色，用一句话概括就是：它是连接AI编程助手和KES数据库的中间层。
当你向AI助手发出"帮我查一下orders表有哪些索引"这样的指令时，IDE会根据MCP协议判断需要调用哪个工具；请求到达KES MCP Server后，Server先做参数校验和权限检查，再连接KES数据库执行对应的操作；数据库返回结果后，IDE再将数据交给大模型进行理解和呈现。
KES MCP Server交互流程
值得强调的是，AI助手并不能绕过KES MCP Server直接访问数据库。模型能调用什么工具、能看到哪些数据，同时受到两个层面的约束：一是Server端配置的访问模式，二是数据库账号本身的权限。这种双层管控机制为数据库安全提供了基本保障。
从技术架构来看，KES MCP Server采用了清晰的分层设计，自顶向下由AI客户端层、传输层、核心服务与安全层、分析能力层和KES数据库层五部分组成。
KES MCP Server分层架构
为了适配不同的使用场景，KES MCP Server提供了三种传输方式，分别对应不同的部署需求。
KES MCP Server传输方式
- Stdio：适合本地开发场景，无需开放端口，开箱即用；
- SSE：可用于需要远程访问的场景；
- Streamable HTTP：更适合集中部署，支持配合HTTPS、反向代理和网络隔离策略。
对于大多数个人开发者来说，本地使用Stdio是最便捷的选择；而在团队共享或跨环境协作时，Streamable HTTP会是更合适的选择。
把AI接入数据库，安全性是绕不开的话题。KES MCP Server对此做了细致的考量，提供了两种访问模式：
- Restricted 模式（推荐）：内置SQL类型白名单与严格的访问控制策略，拦截高风险写操作，从源头阻断非法写入与修改行为。生产环境或演示环境建议启用此模式，并配置AI专用的数据库最小权限账户，双重保险降低误操作风险。
- Unrestricted 模式：开放完整数据库操作权限，支持复杂的管理与开发类指令，适合对灵活性要求更高的测试环境。
两种模式可根据场景自由切换，让"给AI套上缰绳"这件事不再是一句空话。
9个标准工具，四类核心能力
KES MCP Server一共提供了9个标准化的MCP工具，按功能可以归纳为四大类。
▶ 数据库结构探索
你可以让AI帮你查看数据库中有哪些Schema、表、视图和序列，也可以进一步深入查看某张表的字段定义、约束条件和索引详情。比如：
“列出所有Schema下的表。”
“看看orders表有哪些字段，索引建在哪几个列上。”
AI返回的信息全部来自当前连接的KES数据库，是实时、准确的元数据，不再需要你手动把DDL建表语句复制粘贴到对话窗口中。
▶ SQL查询与执行计划分析
这一能力让AI不再是"纸上谈兵"。你可以直接提出业务问题，让AI生成SQL并执行查询：
“帮我查一下本月销售额排名前5的商品。”
也可以让AI分析一条给定SQL的执行计划：
“这条SQL的执行计划是什么样的？有没有走索引？”
KES返回实际的查询结果和EXPLAIN信息后，大模型能够进一步解读——扫描方式是全表扫描还是索引扫描、过滤条件是否高效、索引有没有被充分利用，从而给出有价值的优化方向。
▶ 数据库健康巡检
运维场景同样受益。一条指令就能发起全面健康检查：
“检查一下数据库健康状况。”
KES MCP Server会自动检查索引状态、连接数、Vacuum情况、序列使用率、复制延迟、缓存命中率和约束状态等关键指标。
还可以快速定位"性能杀手"：
“找出最近总耗时最高的5条SQL。”
锁定问题SQL后，就可以顺藤摸瓜，继续分析其执行计划和索引使用是否合理。
▶ 索引优化分析
这是KES MCP Server一个很有特色的能力。它不仅可以针对某条具体SQL或历史查询负载给出索引建议，还支持——结合 sys_hypo 扩展——在不实际创建索引的情况下，模拟新增索引后的执行计划变化。
“如果在user_id和status上建一个联合索引，执行计划会变成什么样？”
KES MCP Server核心能力与适用场景
这意味着你可以在真正执行 CREATE INDEX 之前，先用假设索引验证优化效果。如果模拟结果显示执行代价显著降低，再由开发人员或DBA结合查询频率、写入开销和存储成本，做出最终的变更决策。既有数据支撑，又避免了盲目建索引带来的副作用。
快速上手：三步接入KES MCP Server
想要体验KES MCP Server，你需要准备好：
- KES数据库（V8R6及以上版本）
- Python 3.12 ~ 3.13
- 支持MCP协议的开发工具（如TRAE、Cursor等）
第一步：拉取代码
git clone https://gitee.com/king-db/kingbase-mcp
第二步：安装依赖
uv pip install .
第三步：在MCP客户端中完成配置
在客户端配置文件中设置数据库连接信息、启动命令和访问模式。生产环境强烈建议使用Restricted模式：
uv run kingbase-mcp –access-mode restricted
如果使用Stdio方式，客户端会自动拉起MCP Server进程，无需手动启动。
需要注意的是，索引分析功能依赖 sys_hypo 扩展，慢查询和负载分析依赖 sys_stat_statements 扩展，使用前请确认这些扩展已在KES中启用。完整的配置参数说明可以查阅项目的README文档。
客户端配置及工具加载页面
一个完整的实战案例：从发现慢SQL到验证优化方案
假设你要排查这样一条订单查询的性能问题：
SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';
在支持MCP的IDE中，你不需要离开编辑器。直接输入：
“查看orders表的结构，包括字段、约束和索引。”
KES MCP Server会返回这张表的列定义、主键约束以及当前已有的索引。这一步可以快速确认 user_id 和 status 字段上是否已有可用的索引覆盖。
接着，让AI分析现状：
“分析这条SQL的执行计划。”
如果返回结果显示这条查询走了全表扫描，或者现有索引并未生效，那就可以验证新的索引方案——直接让AI模拟在 user_id 和 status 上增加联合索引后的执行计划。KES MCP Server会通过 sys_hypo 的假设索引能力，生成新的执行计划，并与之前的计划做对比。
整个过程不会在数据库中真正创建物理索引，也不会引入任何额外的存储和维护开销。
如果模拟结果显示扫描方式从全表变成了索引扫描，执行代价大幅降低，那么优化方向就得到了数据验证。接下来，由开发人员或DBA结合实际的查询频率、写入压力和存储成本，决定是否真正落地这个索引变更。
从表结构查看，到执行计划分析，再到优化方案验证——这些原本需要切换多个工具、在多个窗口之间反复横跳的操作，现在在一个IDE的对话框中就能一气呵成。
