电科金仓KES开发大赛赛道解读：SQL优化、巡检、容量预测怎么选？

大家好，我是数据库小学妹 👋

最近在做一个智能监控告警的事情。整理KWR报告、写巡检脚本、对接大模型做异常分析。前前后后折腾了一个多月。

做得越深越发现，日常巡检靠人工、告警来了靠经验、磁盘满了靠救火。工具要么太重、要么太贵、要么不好用。想自己写一套，又不知道从哪下手。

正好看到2026金仓数据库智能运维工具开发大赛在报名。一看赛道设置，SQL优化、巡检、容量预测都有。基本覆盖了我这段时间在做的事。研究了一圈赛事资料，把8条赛道的技术要点和选型思路整理出来。准备参赛的朋友可以参考。

这个大赛在比什么

简单说，就是基于KES数据库和BIC-QA系统来开发智能运维工具。

BIC-QA是个AI驱动的诊断平台。底层攒了5000多个真实故障案例，构建了数据库知识图谱。你查一个等待事件，它能告诉你这个事件属于哪一类、通常是什么原因引起的、该怎么优化。平台还提供了Python SDK，可以直接调大模型做智能分析，不用自己搭AI环境。

开发模式有两种。一种是调BIC-QA的API做分析，另一种完全自主开发。两种都行，选自己擅长的。

做出来之后，作品需要包含分析诊断模块，以及配套的PPT、演示视频和项目代码。数据采集模块是加分项，做了会加分，不做也不影响。

最终能不能拿奖，评审主要看两样东西。一是你的方案有没有创新性，落地质量怎么样，这两项各占30分，是大头。二是AI融合度，占25分——光用规则引擎不行，得把大模型或知识图谱用起来。剩下15分给交付质量，代码规范、文档完整、演示清晰。进决赛还有现场答辩，按作品70%加答辩30%算总成绩。交付质量里有个容易被忽略的要求：作品需要能在海光CPU服务器环境中正常运行，写代码时别用平台相关的依赖。

8条赛道，我在意的4条

8条赛道覆盖了数据库运维各个方向。巡检、KES诊断、SQL优化、KWR报告分析、参数合理性、容量预测、锁冲突分析。还有一条开放赛道。

全讲一遍太散了。我挑了4条技术含量高、和实际运维贴合紧密的赛道，重点拆解。

SQL优化：经验能直接用上的一条赛道

做DBA的都有过这种经历：一个慢查询拖垮整个系统。看了半天执行计划，发现是索引选错了。这种问题靠人能解决，但靠人一个一个查太慢。

这条赛道可以用组委会提供的SQL测试用例，也可以自己设计。测试用例包含难度分级。

我的理解是，SQL优化对有经验的DBA比较友好。平时怎么分析慢查询、怎么看执行计划。怎么加索引、怎么改写SQL。这些经验能直接迁移过来。

难点在于结合AI。单纯做SQL改写规则不够，评分里智能技术融合度占25分。得把大模型用进来。比如用BIC-QA的chat接口做SQL语义分析。或者用知识图谱匹配优化建议。实际落地时，可以分两步走：第一步用规则引擎处理常见的索引缺失、隐式类型转换；第二步把复杂查询交给大模型做语义级别的改写建议。

这条赛道适合：有SQL调优经验、想把经验产品化的人。

KES诊断：知识图谱帮你补经验缺口

数据库出问题的时候，最难的不是解决问题，而是定位问题。CPU高了、IO满了、连接数爆了——症状一堆，根因只有一个。靠经验排查，快的几分钟，慢的可能要翻一天日志。

这条赛道要求对KES做智能诊断分析。可以借助BIC-QA知识图谱中的等待事件、TIMEMODEL和指标知识点。

如果你之前主要做MySQL或Oracle，对KES的等待事件体系不太熟。BIC-QA的知识图谱能帮你补上这块。调get_wait_events_info就能拿到等待事件的分类和优化建议。

KES有自己的性能诊断工具链。KWR负责定期采集性能快照，KSH记录活跃会话历史。KDDM能基于快照自动给优化建议。做这条赛道，可以把这些数据源都用起来。把KWR快照喂给大模型做趋势分析，再结合知识图谱给出优化建议。这个思路评审应该会认可。

容量预测：把DBA的"感觉"变成数据

磁盘使用率85%了，领导问还能撑多久。你说"大概两个月"。结果一个月就满了。这种事做过运维的人都遇到过。

这条赛道要解决的就是这个问题——用时序预测模型，把历史资源数据喂进去，输出未来半年到一年的使用趋势。技术门槛不算高，真正拉开差距的是预测结果的解释能力。你得让非技术的领导看得懂报告，这块可以借助BIC-QA的大模型接口做报告生成。

锁冲突和阻塞分析：生产环境的老大难

凌晨三点被告警叫醒。登上数据库一看，几十个会话在等锁。事务互相卡着，业务全部超时。排查锁等待链的时候，一个一个查会话，光理清谁等谁就要半小时。长事务持锁不放，会话之间互相等待，最终整个系统卡死——做过生产运维的都经历过这种场景。

这条赛道就是要基于sys_stat_activity等视图的数据，把锁冲突和阻塞情况自动分析出来。如果能把锁等待链自动画出来，结合知识图谱里的锁事件说明，自动给出根因和处理建议，这个工具在生产中会非常实用。

以上4条是我重点研究的，剩下4条也各有适用场景。我把8条赛道整理成一张对照表，方便根据自己的背景做选择。

选型对照表

选赛道有个原则。选自己踩过的坑，比选觉得酷的方向更靠谱。评审看的是落地性。

开发环境和关键流程

赛道选好了，接下来就是搭环境写代码。不管选哪条赛道，开发流程是通用的。

先在金仓社区注册报名，拿到API Key。然后下载赛事资料包，里面包含SDK源码、脚本模板和示例数据包。

SDK的核心是CommUtil.py和deepseek_chat_awr.py。前者把数据库参数、性能指标、等待事件这些知识点封装成了查询接口，后者对接大模型做智能分析。两个文件配合使用，几行代码就能跑通一条完整的诊断链路。

采集和分析要分开，这是赛事的明确要求。实际流程分四步：写采集脚本连KES查数据，输出txt数据包；写分析脚本读取数据包做诊断，输出Markdown报告；把分析脚本上传到BIC-QA平台审核；用数据包提交诊断，等平台生成HTML报告。

赛事资料包里有完整的示例代码。Freeze分析工具的全流程可以直接参考。采集脚本、分析脚本、SDK调用，都写好了。改改连接信息和分析逻辑就能用。

建议先把示例跑通，再基于自己的赛道方向改造。别一上来就从零写，容易在环境配置上浪费时间。

回过头来看，这个大赛和纯写代码的比赛不一样。知识图谱、大模型接口、性能快照工具，这些基础设施都是现成的。你真正要比的，是谁更懂运维场景，谁能把踩过的坑变成工具里的分析逻辑。

想参赛的朋友记得去金仓社区报名，截止7月31日。个人或2到3人团队都可以。

大家觉得哪个赛道最值得做？欢迎评论区聊聊 👋

我是数据库小学妹，咱们下篇见 👋