openGauss数据库源码解析——慢SQL检测

本文介绍了openGauss数据库如何通过训练模型预测SQL执行时间,区分慢SQL,并详细阐述了基于执行计划的DNN模型和MART模型,以及SQL模板化的流程。还讨论了这两种方法的优缺点和应用策略,包括深度学习模型的增量训练和SQL模板的存储与预测过程。
摘要由CSDN通过智能技术生成

openGauss 数据库源码解析——慢 SQL 检测

慢 SQL 检测的定义:

基于历史 SQL 语句信息进行模型训练,并用训练好的模型进行 SQL 语句的预测,利用预测结果判断该 SQL 语句是否是潜在的慢 SQL。当发现潜在的慢 SQL 后,开发者便可以进行针对性优化或者风险评估,以防业务上线后发生问题。

慢 SQL 检测的功能:

上线业务预检测:上线一批新业务前,使用 SQL 诊断功能评估此次上线业务的预估执行时长,便于用户参考是否应该修改上线业务。workload 分析:能够对现有 workload 进行分析,将现有 workload 自动分为若干类别,并依次分析此类别 SQL 语句执行代价,以及各个类别之间的相似程度。

首先,明确一下慢 SQL 发现的几个不同阶段,及其对应解决的问题。

阶段 1:对用户输入的一批业务 SQL 语句进行分析,推断 SQL 语句执行时间的快慢,进而可以将评估为慢 SQL 的语句识别出来。

阶段 2:对识别出的潜在慢 SQL 进行根因诊断,判断这些 SQL 语句是因为什么慢,例如比较常见的原因可能是数据量过大、SQL 语句自身过于复杂、容易产生并发的锁冲突、没有创建索引导致全表扫描等等。

阶段 3:对于已经识别出来的慢 SQL 语句的可能问题源,给出针对性的解决方案,譬如可以提示用户进行 SQL 语句的改写、创建索引等。

目前 openGauss 已具备阶段 1 的能力,正在推进阶段 2 能力,同时发布了部分阶段 3 的能力,如索引推荐功能。业内对于上述第一阶段的主要实现方法大部分是通过执行计划进行估计的,第二阶段大多是通过构建故障模式库、通过启发式规则来实现的,有了上述前两个阶段的准备,第三阶段的实现往往是比较独立的。学术界对于第一阶段的研究比较多,第二阶段采用常规的构建故障模式库的方法实现已经能取得比较好的效果了,因此并不是研究的热点,而第三阶段的工作又相对独立,可以单独作为一个领域进行研究。

基于执行计划的 DNN 模型:

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值