“orders这张表上都有哪些字段索引是怎么建的”“帮我看看这条SQL慢在哪里。”“如果给user_id和status加个联合索引执行计划会变吗”这些过去要让DBA或开发人员来回切工具、复制粘贴才能回答的问题如今在TRAE、Cursor这类支持MCP协议的开发工具里直接问一句就能拿到答案。最近电科金仓在Gitee开源了KES MCP Server首批放出9个标准工具把数据库结构浏览、SQL执行、执行计划解读、健康巡检、慢SQL定位、索引优化建议等高频场景一次性接进了大模型工作流。为什么需要KES MCP Server以前的排查链路是断开的开发人员在IDE里写SQL发现慢了得切到数据库客户端查表结构、看索引、跑EXPLAIN再把结果贴回对话框交给大模型分析。来回切换不仅费时信息还容易在搬运中失真。KES MCP Server做的事情就是把这条断开的链路接上——把原本散落在数据库客户端里的操作封装成模型能直接调用的标准工具让AI在真实的KES数据库环境里完成查询与分析。它是怎么工作的整套链路分成三段用户提问在开发工具中用自然语言提出需求。工具调度开发工具判断该调用哪个MCP工具把请求交给KES MCP Server。安全执行Server完成参数校验与访问控制连接KES执行操作再把结果返回给模型继续分析。需要强调的是开发工具不会绕过MCP Server直接访问数据库。模型能调用哪些工具、能跑什么SQL、能看哪些对象既由Server的访问模式决定也受底层数据库账号权限的二次约束。在架构上KES MCP Server采用五层分层设计AI客户端层、传输层、核心服务与安全层、分析能力层、KES数据库层自上而下各司其职。三种传输方式匹配不同部署场景为兼顾本地单机和团队共享KES MCP Server提供三种传输方式Stdio本地开发首选无需开放端口客户端自动拉起服务。SSE适合远程访问场景。Streamable HTTP更适合配合HTTPS、反向代理、网络隔离做集中部署团队共用一套服务。日常单机开发用Stdio即可要跨环境共享或做集中化管理再切到Streamable HTTP。安全先给AI这匹野马套上缰绳数据库是核心基础设施而AI更像一匹野马。让它接触数据库之前第一件事不是放权而是拴好缰绳。KES MCP Server在安全上做了两层设计Restricted 模式默认推荐内置SQL类型白名单 严格的访问控制策略从源头拦截高风险写入与修改。生产环境、演示环境建议默认启用。同时强烈建议为AI单独配置一个最小权限的数据库账户多重防护降低误操作风险。Unrestricted 模式开放完整操作权限方便测试环境里跑复杂的管理和开发类指令。两种模式可按场景自由切换。KES MCP Server能做什么四类核心能力KES MCP Server把KES的常用操作封装成四类标准能力。1. 浏览数据库结构支持查看Schema、表、视图、序列也能下钻到字段、约束、索引等对象详情。比如“列出指定Schema下的全部表、视图和扩展。”“看看orders表的字段、约束、索引。”返回内容直接取自当前KES数据库不用再把建表语句搬进对话窗口。2. 执行查询并分析执行计划既能按业务需求生成并执行查询也能让KES返回真实的执行计划“查询本月销售额排名前5的商品。”“分析这条SQL的执行计划。”模型拿到执行计划后会进一步解读扫描方式、过滤条件、索引命中情况帮你定位性能瓶颈。3. 数据库健康巡检一句指令即可发起全面体检“检查一下数据库健康状况。”Server会依次检查索引、连接、Vacuum、序列、复制、缓存、约束等多个维度。定位问题SQL也很方便“找出最近总耗时最高的5条SQL。”发现问题后可以无缝衔接执行计划和索引分析。4. 索引方案分析含虚拟索引针对指定SQL或历史查询负载做索引分析配合sys_hypo扩展还能在不真实创建索引的情况下模拟新增索引后的执行计划“如果在user_id和status上加联合索引执行计划会怎么变”先评估再落地避免无谓的存储和维护成本。上手指南三步跑起来前置条件KES V8R6 及以上版本、Python 3.12–3.13、TRAE/Cursor 等支持MCP的客户端。第一步拉代码gitclone https://gitee.com/king-db/kingbase-mcp第二步装依赖uv pipinstall.第三步客户端里配置在MCP客户端中填好数据库连接、启动命令和访问模式。生产/演示环境建议启用Restricted模式uv run kingbase-mcp --access-mode restricted使用本地Stdio方式时客户端会自动启动服务无需手动跑进程。小提示索引分析依赖sys_hypo扩展慢查询和负载分析依赖sys_stat_statements扩展完整参数可参考项目README。实战在IDE里完成一次完整SQL优化假设要排查这条订单查询SELECT*FROMordersWHEREuser_id123ANDstatuspending;第一问看结构“查看orders表的结构包括字段、约束和索引。”Server返回当前结构和索引情况帮你判断查询字段是否已有可用索引。第二问看计划“分析这条SQL的执行计划。”如果发现走了全表扫描、或现有索引没命中就进入第三步。第三问验索引“模拟增加user_id和status联合索引后的执行计划。”Server通过虚拟索引重新生成执行计划并对比加索引前后的变化。整个过程不创建任何物理索引零存储、零维护成本。如果模拟结果明显改善再由开发或DBA结合查询频率、写入压力、存储成本决定是否真正落地。从看结构、看计划到验索引原本散落在多个工具里的操作现在在一个开发环境中就能闭环。
)
)
