我要投稿

用 DeepSeek 识别分析“TOP SQL”

发布日期：2025-04-29 07:42:31 浏览次数： 1524 作者：韩锋频道

TOP SQL，是 DBA 经常需要关注的语句，这些语句往往是执行频次高、执行时间长、资源开销高的语句。这些语句也成为 DBA 优化的重点。但这里有一个问题就是，上述这些语句真的是需要优化的吗？其实，针对这些语句如果是稳态运行的话，是不需要太多关注的，因为它们不会成为未来影响稳定运行的“X 因素”，反而是哪些不稳定的、即将变差的、存在毛刺的等语句反而是需要更多关注的。然后我们在各种常规的监控平台、工具上通常只能看到前者这些语句，而针对后者这些语句反而无从下手。本文就是尝试从另一个角度入手，通过 DeepSeek 对语句执行的日志进行分析，将原来需要繁琐的程序处理简化到不用写代码，简单文字交互处理即可。

1. 环境准备：模拟日志+文字交互

这里简化测试环境，使用 BenchMark 数据作为基础数据。一方面通过自己写的小程序，模拟应用定时执行指定SQL；另一方面通过执行 BenchMark 增加环境噪声。针对上面的执行结果记录到日志文件中，记录的信息是执行时间和SQL执行时长。这里执行了两组，一组是单独执行SQL，一组是在执行过程中增加了环境负载的情况，分别对应两个输出的日志文件，并上传给 DeepSeek。

提示词

上传文件是两组时序数据，针对这些数据进行分析并图形化展示。

1.时序数据格式

1).数据使用逗号分隔

2).第一列含义为SQL语句的执行时间，第二列为SQL语句的执行时长

2.图形化输出要求

1).格式为HTML

2).输出的HTML代码中包含完整的数据

3).输出图形沾满整个窗口

4).采用光滑折线图方式

5).针对两组数据上下分列显示并采用相同的量程

3.数据分析要求

1).输出SQL的执行情况

从上面图中可以看到，第一组数据SQL执行较为平滑（如上图），第二组数据SQL执行较为陡峭（如下图）；其原因是在第二组执行过程中，中间施加了一些环境干扰，导致语句执行时间增长。

2. 了解整体执行情况 — 统计分析

我们先整体了解下运行情况，这里可利用一些标准的统计函数来完成，交给 DeepSeek 看看情况如何？

提示词

针对上面第二组数据，使用Python3分析其SQL语句执行特征，以图形化的方式输出，包括但不限于执行时长的平均值、中位线等指标

从这里可以看出信息量还是很丰富的，不仅包含了运行时长、平均值、中位数等常规的，还包括了密度分布、箱式图（后文会讲）等内容。从中我们可以观察到一些情况，例如平均值>中位数，这表明存在右偏分布（少量高耗时查询拉高均值）。再例如执行时长密度分布存在双峰现象，说明存在两种典型的执行特征（快查询与慢查询）等。

3. 反映运行稳定度指标 — 时间方差

方差（Variance）是衡量数据离散程度的统计量，反映数据与平均值（均值）的偏离程度。方差越大，数据波动越大，分布越分散；方差越小，数据越集中，稳定性越高。方差的计算公式如下

那么在针对SQL执行特征方面，方差可以起到评估SQL执行是否稳定的作用。低方差，表示执行情况平稳；高方差则表示执行时间波动大，可能存在偶发性能问题。针对后者一般可考虑检查索引、索竞争、资源瓶颈等。为了更好地展示对比，这里引入一个概念叫“箱式图”，是一种用作显示一组数据分散情况资料的统计图。因形状如箱子而得名，能显示出一组数据的最大值、最小值、中位数及上下四分位数。

下面针对上面两组执行情况，做一个方差分析。这里可以充分利用 DeepSeek 的能力，不需要自己写程序分析了。

提示词

针对上面数据做方差分析，并将结果通过箱式图来展示。

从图中我们可以直观看到第一组的执行情况的时间分布更为集中，而第二组则明显差异很大，两者方差差异明显。这也说明第二组执行时出现了明显的抖动情况。同时上面图形中也显示出一些常用的统计指标，包括极数值（最大值、最小值）、中位数等。

4. 找到语句运行“拐点” — PELT算法

所谓拐点，就是其运行特征前后发生巨大变化的情况，这通常对应于性能恶化或恢复正常的场景。那么如何在大量SQL运行信息中找到语句运行出现拐点的时刻，对于事后排查分析很重要。这里可以利用 DeepSeek 的能力帮助我们找到这个拐点。我们将这个问题提给 DeepSeek 看它如何反应？

提示词

针对上面数据做拐点分析，并将结果图形化展示出来。

DeepSeek 思考过程中找到多种识别算法，并最终选择了PELT算法。因为这种算法有Python包实现，DeepSeek 给出了源码，稍加修改就可以使用。简单说明下PELT算法，PELT（Pruned Exact Linear Time）算法是一种高效的变点检测方法，其核心思想是通过动态规划结合剪枝策略，在保证检测精度的同时实现线性时间复杂度。该算法以最小化分段成本与惩罚项之和为目标，递归地搜索时间序列中的最优变点组合。其核心步骤包括：1）初始化动态规划数组，记录不同位置的最小累积成本；2）迭代计算每个时间点的最优前驱节点，利用成本函数（如L2均方误差或RBF核函数）评估数据分布的突变程度；3）通过剪枝策略剔除不可能成为最优解的候选点，显著减少计算冗余。惩罚项参数（通常基于BIC准则）动态平衡检测灵敏度与过拟合风险，低惩罚值倾向捕捉细微变化，高惩罚值侧重显著突变。该算法尤其适用于金融波动分析、物联网设备监测等需要实时处理大规模时序数据的场景，在检测精度与计算效率之间实现了理想平衡。上述内容看起来很拗口，没关系我们实用看看。针对上面测试数据，运用这一算法输出如下图形

运用PELT算法，可以找到SQL执行出现拐点的情况。如上图在第一时间点，系统开始出现高延迟查询的情况，此时的执行时长均值从0.051上涨到0.097（上涨90%）；在第二时间点，系统恢复正常，执行均值下降了50%。从上面应用可以看出，PELT算法在数据库SQL性能分析中如同一位智能巡检员，能够自动识别SQL执行过程中的异常波动时刻，帮助管理员快速定位性能瓶颈。其核心作用体现在三个方面：首先，精准捕捉突变时段。通过扫描SQL执行时间序列，PELT能智能识别执行时长突然飙升的时间节点（如从0.05秒陡增至0.5秒），这些拐点往往对应着缓存失效、锁竞争或索引缺失等问题。其次，区分自然波动与真实异常。相比传统阈值告警（如固定0.1秒为慢查询），PELT通过动态惩罚机制，能过滤日常负载波动（如早晚高峰的规律性延迟），专注检测非正常突变（如某时刻因全表扫描导致的持续性高耗时）。最后，提升根因分析效率。当算法标记出某时间点为异常拐点后，管理员可直接调取该时段的执行计划、资源监控日志，快速定位是SQL写法缺陷（如未使用索引）、硬件瓶颈（如CPU跑满）还是并发冲突（如死锁堆积）所致。

5. 找到语句运行“毛刺”— 异常点检测

毛刺，是指执行特征有别于绝大部分正常情况的异常点。这些点对于用户来说，通常会存在使用体感的明显变化，如突然变得非常卡顿等。这些点通常在做事后分析时，会感觉到无从下手，那么看看 DeepSeek 能帮助我们做什么？

提示词

对上述数据做异常点检测分析，并通过图形化方式展示结果

通过思考，DeepSeek 使用到异常点检测通过多维算法融合机制精准捕捉数据库执行中的异常行为。其生成的Pytho程序，稍加修改即可使用。程序采用Z-score、滑动窗口统计和孤立森林三重检测策略：Z-score基于正态分布假设，计算每个执行时长与整体均值的标准差距离（公式：z=σx−μ），能有效识别突破3σ阈值的全局离群点，如某SQL耗时突增至0.141秒（超均值5倍）；滑动窗口法（窗口=5）动态计算局部均值与标准差（μwin+2σwin），擅长捕捉持续时间超过10秒的异常窗口，例如缓存失效引发的连续性高延迟；孤立森林通过构建随机二叉树快速隔离异常路径，对非高斯分布的隐蔽异常（如0.057秒的早期波动）具有独特敏感性。三者的逻辑或组合策略共同决定异常点。当然这里存在一点误差，即初始点被误标为异常，核心原因在于算法对早期孤立波动的敏感性。具体如下图所示

通过上图可以看出，这种机制在真实业务场景中可有效识别三类典型问题：1）索引失效引发的全表扫描（表现为单点Z-score异常），2）锁竞争导致的持续阻塞（滑动窗口连续异常），3）内存泄漏引发的渐进式性能劣化（孤立森林路径异常）。通过可视化模块的95%分位线（紫色虚线）与异常热力图，DBA 可快速定位出现异常的时间段范围。

6. 物以类聚，有的放矢 — 聚类分析

除了上述针对一条语句的分析外，另外值得关注的是针对全量语句特征的分析。这里可以采用聚类分析的方式，下面是模拟了四种类型的SQL语句，针对执行频次和执行时长做了了聚类。这里简单说明下聚类分析，聚类分析是一种无监督机器学习方法，旨在根据数据特征的相似性将样本划分为若干组（簇），使同一簇内样本高度相似，不同簇间差异显著。在SQL分析场景中，选取执行频次（单位时间执行次数）和平均执行时长作为特征，通过标准化处理消除量纲差异后，利用聚类算法将SQL语句划分为不同执行模式类别。下面我们看看执行情况

提示词

上传的sql1,sql2,sql3,sql4四个文件，表示四条语句在数据库中的执行情况。里面的字段分别对应执行时间和执行时长，请根据执行频次和执行时长两个维度入手，做SQL语句执行特征的聚类分析，并通过图形化的方式展示出来。

通过上图可见，我们将SQL精确分类，并做有针对性的优化。一类是高频低耗型（如sql2）：频繁执行但耗时短，需确保其执行计划稳定，避免索引失效或资源争用；一类是低频高耗型（如sql3、sql4）：执行次数少但单次耗时长，应优先优化，例如重构查询逻辑、添加索引或缓存结果；还有一类是过渡型（如sql1）：频次和时长均居中，需监控潜在性能劣化风险。聚类结果直观展示不同SQL的性能影响权重，指导DBA按“低频高耗 > 高频低耗 > 过渡型”顺序制定优化计划，最大化投入产出比。聚类分析通过数据驱动方式揭示SQL执行特征，替代人工经验分类，提升优化效率。但其效果依赖特征选取（如增加峰值时长、资源消耗指标可增强区分度）和簇数设定（可通过“肘部法则”选择最佳K值）。此外，需结合业务场景解读结果，避免单纯依赖数学划分忽略实际语义。例如，高耗时的低频SQL可能是关键报表查询，需保障其稳定性而非盲目削减耗时。综上，聚类分析为SQL优化提供了科学的分类框架，辅助DBA从海量日志中快速定位重点问题，是实现数据库智能调优的手段之一。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费场景POC验证，效果验证后签署服务协议。零风险落地应用大模型，已交付160+中大型企业