站在DeepSeek的肩膀上，我用zCloud看到企业级SQL性能优化的更多可能性

云和恩墨 2025-03-06

文/郎俊软件架构师

作为一名DBA，我深知数据库的SQL性能优化至关重要。然而，由于SQL执行机制的多样性和复杂性，优化一个SQL，特别是复杂SQL，需要耗费大量的时间和精力。因此，我对SQL优化一直怀有很强的敬畏之心。直到最近，我听闻 zCloud 集成了 DeepSeek，推出了SQL AI分析功能。试用之后，我觉得它或许很快会改变DBA在这项工作上的现有模式。

我先讲讲具体的试用过程。我提前模拟了一个性能欠佳的SQL并执行多次，以便让 zCloud 的性能分析功能识别出这条TOP SQL。

可以注意到，最新版本的 zCloud 在每条SQL ID的悬浮小窗里都增设了一个【AI分析】按钮，点击后会打开一个针对该SQL的对话式优化界面。它能借助原生 DeepSeek 的自然语言理解能力和强大的推理能力，通过AI助手自动分析并给出优化建议。

AI助手从多个维度给出了优化建议。我知道这条SQL最关键的问题在于缺少索引，而AI助手果然把索引作为首选推荐的优化方案，不仅给出了具体的索引及创建命令，还说明了推荐该索引的原因。

让我惊讶的是，它推荐的联合索引中字段顺序完全正确。DBA都知道，联合索引的字段顺序应依据选择度来排列，这表明 zCloud 将SQL对应的表字段的统计信息输入给了大模型，同时让大模型成功注意到了这些信息。

我按照AI助手给出的索引创建命令创建了索引，SQL执行时间从原来的3秒多大幅缩短至10多毫秒。

如图所示，优化前：执行计划显示整个查询过程涉及多种复杂操作，耗费时间较长。

优化后：执行计划在相关关键步骤上有明显改进，执行时间显著减少。

事实上在日常工作中，我也经常借助 DeepSeek 来完成一些任务。于是，我把同样的SQL交给 DeepSeek（网页版）分析，并启用了深度思考模式。得到的结果是这样的：

可以发现，DeepSeek 的思考逻辑严密，数据库知识也比较全面。它推荐了索引，包括索引字段也都正确，但其推荐的索引却未能提升SQL的性能。从执行计划可以看出，该索引未被使用。

究其原因，是c2和c1的选择度很低，c3选择度较高，而 DeepSeek 并不知道这些信息，所以推荐的联合索引中的字段顺序有误，致使执行计划没有采用该索引。这也从另一个侧面说明了“zCloud 将SQL对应的表字段的统计信息输入给了大模型”的重要性。

这不禁让我感叹，即便拥有再强大的“大脑”，若没有获取信息的“眼睛”，终究难以发挥出全部实力。

人类的任何工具都是一层一层的“工具栈”堆叠而成，这种方式推动着人类的科技得以不断快速进步。一些伟大的工具或技术能够实现人类整体科技基础的飞跃式提升，以 DeepSeek 为代表的生成式AI便是其中之一。

有人说，基于大模型开发的应用在技术上的门槛很低。这种说法对于消费级软件而言或许尚可接受，因为面向大众的软件，技术在其竞争力构成中可能并非最关键的因素；但对于企业级应用，特别是像数据库管理平台这种企业级专业软件，为了满足专业性、可靠性、易用性等多方面的要求，必然在技术上有着更高的标准，构建较高的技术门槛也就成为必然。这种门槛不会因先进技术或工具的普及而消失，反而会持续进化，促使厂商基于最先进的技术打造更优质的产品。

云和恩墨便是这样的厂商，zCloud 便是这样的产品。3月底，AI加持的 zCloud 全新版本将正式发布，敬请期待！

zcloud sql优化性能优化 deepseek 数据库智能运维

最后修改时间：2025-03-06 18:17:20

文章转载自云和恩墨，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

站在DeepSeek的肩膀上，我用zCloud看到企业级SQL性能优化的更多可能性

评论

相关阅读