一种索引自动优化方法及装置与流程

文档序号:19929956发布日期:2020-02-14 21:53阅读:193来源:国知局
一种索引自动优化方法及装置与流程

本发明涉及数据搜索领域,尤其涉及一种索引自动优化方法及装置。



背景技术:

随着互联网技术的发展,数据查询在越来越多的场景下得到了应用。在数据查询系统中,用户可以向服务器发送查询指令,服务器从数据库中查询对应的数据。但是随着数据库中存储总信息量的增加,传统的数据查询检索方法速度会大幅度降低,无法满足现有的数据检索要求。

因此,为了优化数据查询的速度,数据库可以采用索引的方式进行数据查询。其中,索引是在数据库中创建的一些用于指向数据库中某一列数据具体存储位置的存储结构。其作用类似书籍的目录,在数据查询时可以直接从索引中寻找符合查找条件的数据的具体存储位置。由于索引中可以不包含数据的具体内容,可以大幅度提升查询速度。

但是,数据库在使用索引进行数据查询时,有小概率会错误使用索引,这些错误会不断累积。随着数据查询业务量的增加和系统长时间持续运行,数据库会累积大量错误的情况,导致查询速度降低,严重影响用户的体验。目前解决索引错误需要研发人员手动排除,不但耗费人力物力,而且还存在效率低、无法完全解决索引错误的问题。



技术实现要素:

有鉴于此,本申请实施例提供了一种索引自动优化方法及装置,旨在不需要研发人员参与的情况下自动监测查询进程,并针对索引出现的问题进行自动优化。

为了实现上述目的,本发明提供了以下技术方案:

一种索引自动优化方法,所述方法包括:

采集慢查询进程日志信息;其中,所述慢查询进程为执行时间超过预设时间的查询进程;

对所述慢查询进程日志信息进行分析,确定错误原因;其中,错误原因是根据预先存储的日志信息异常情况和错误原因对照关系确定的;

根据所述错误原因选择对应的优化方案进行优化。

可选地,所述采集慢查询日志信息包括:

设定慢查询进程预设时间;

实时记录查询进程执行时间;

根据所述执行时间从进程池中选择执行时间超过预设时间的慢查询进程。

可选地,所述慢查询进程日志信息至少包括以下的一个或多个:

索引信息、锁定时间、返回记录、访问计数、查询时间、平均锁定时间。

可选地,所述错误原因至少包括一下的一个或多个:

索引为空、索引聚合、锁竞争、索引不合理。

可选地,所述方法还包括:

当所述优化方案无效时,删除现有索引并重建索引。

可选地,所述优化方案至少包括一下的一个或多个:

创建新索引、重建索引,顺序删除索引、删除部分索引内容。

可选地,所述方法还包括:

在完成对索引的优化后,对所述慢查询进程进行循环检测。

一种索引自动优化装置,所述装置包括:

日志记录单元,用于记录慢查询进程的日志信息;

日志分析单元,用于对所述慢查询进程日志信息进行分析,确定错误原因;

优化单元,用于根据错误原因选择优化方案进行优化。

可选地,所述日志记录单元包括:

时间设定单元,用于获取并设定预设时间;

进程监控单元,用于记录查询进程执行时间;

比较单元,用于根据所述执行时间判断所述进程是否为慢查询进程;

日志输出单元,用于将所述慢查询进程的日志信息输出至指定路径。

可选地,所述优化单元包括:

优化方案选择单元,用于根据错误原因选择对应的优化方案;

优化方案执行单元,用于执行所述优化方案。

本申请实施例提供了一种索引自动优化方法及装置。通过采集慢查询进程日志信息,并对所述慢查询进程日志信息进行分析,确定错误原因,再根据所述错误原因选择对应的优化方案进行优化。可以实现数据库中索引的故障检测和自动优化,防止数据查询业务因索引的错误使用导致的性能降低。

附图说明

为更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1为本申请一实施例提供的索引自动优化方法图。

图2为本申请一实施例提供的慢查询进程确认流程图。

图3为本申请一实施例提供的索引优化的流程图。

图4为本申请一实施例提供索引自动优化装置图。

具体实施方式

本申请实施例提供了一种索引自动优化的方法及装置。可以理解,本申请提供的索引自动优化方法可以应用于任意具有索引和数据查询能力的数据库或数据查询系统。其中,数据库可以是独立的服务器,也可以是分布式数据库。为了便于理解,本申请主要使用关系型数据库为主题进行实例性说明。

在现有的关系型数据库中,索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构。它可以是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单。索引的作用相当于图书的目录,可以根据目录中的页码快速找到所需的内容。当表中有大量记录时,若要对表进行查询,可以在表中建立索引,然后在索引中找到符合查询条件的索引值,最后通过保存在索引中的rowid(相当于页码)快速找到表中对应的记录。

但是,在数据查询系统上线之后,随着数据查询业务量的增加和系统长时间持续运行,会发现数据查询系统运行越来越缓慢,严重影响用户的体验。导致查询业务运行缓慢的原因有很多,其中数据库运行缓慢是其中一个主要原因,而数据库运行缓慢的主要原因是由于索引的错误使用(80%)导致对应的查询性能低效,从而严重影响业务系统的吞吐量。目前的方案都是人为参与完成,浪费大量的时间并且定位效率太差,并且对研发人员要求较高,会大幅度增加数据查询系统的运维成本。进一步地,由于研发人员的主观原因,每次对索引进行优化时,难以将数据查询系统中索引的全部问题一次解决,可能存在遗留的问题。同时也无法实现索引的实时优化。

针对现有的数据查询系统存在的问题,为了给出数据库中自动优化索引的实现方案,本申请实施例提供了一种索引自动优化方法及装置。以下结合说明书附图对本发明的优选实施例进行说明。

图1为本申请一实施例提供的一种索引自动优化方法流程图,包括:

101:采集慢查询进程日志信息。

在本实施例中,数据库可以查询采集慢查询进程的日志信息。具体地,可以在服务器的配置文件中配置慢查询进程筛选条件和慢查询进程日志输出路径。以数据库配置参数的形式在数据库后台对全部数据查询进程进行监控。并记录采集到的慢查询进程日志日志信息。

其中,慢查询进程是根据慢查询进程筛选条件从进程池中选择的进程。例如,可以将慢查询进程筛选条件设为某个预设时间。服务器可以在后台实时监控数据库进程池中全部查询进程的运行时间。预设时间可以是研发人员在创建数据库时就预先设计好的,也可以是服务器根据进程的实际情况自动设置的,代表了某些查询进程理论上的运行时间。除此以外,配置文件中还可以有慢查询进程日志信息的输出地址,在找到慢查询进程时,可以自动将其日志信息输出到输出地址对应的存储位置中,

例如,当检测到进程池中某个查询进程运行时间超过预设时间时,服务器可以认为这个进程的执行时间超过了理论值,可能是索引的错误使用或者其他原因导致进程运行缓慢。此时服务器可以根据预先配置好的输出地址,在指定存储空间存储慢查询进程的日志信息。

进一步地,本实施例中采集慢查询进程日志信息的同时还可以获取业务表对应的索引信息。例如可以通过调用数据库的内置视图获取索引信息。

本申请实施例中服务器可以实时监控数据库中全部进程,从中选择运行时间超过预设时间的进程定义为慢查询进程并在指定路径存储其日志信息。实现了数据库中查询业务的实时监控,是后续步骤实现索引自动优化的基础与保证。

102:对所述慢查询进程日志信息进行分析,确定错误原因。

在本实施例中,服务器在获取到慢查询进程的日志信息后,可以对采集到的日志信息进行分析,确定慢查询进程索引出错的原因。在一些实现方式中,可以通过对日志信息中各个参数进行具体分析,确定进程响应时间过长的原因。具体的,服务器中可以预先存储日志信息异常情况和错误原因的对照关系,并根据采集到的日志信息包含的异常情况确定错误原因。

在一些实现方式中,所述日志信息可以包括:索引信息、锁定时间、返回记录、访问计数、查询时间、平均锁定时间等一种或多种。服务器可以对这些信息进行分析,根据日志信息中的具体值进行判断具体出现的问题。

例如,服务器可以对针对采集到的慢查询日志执行mysql执行计划统计该sql使用的索引信息,根据预先存储的预先存储日志信息异常情况和错误原因对照关系,判断当前进程是否存在索引为空或索引聚合的问题;可以通过记录数据查询时不同锁对应的锁定时间判断是否出现锁竞争;可以通过查询慢查询进程中每个sql语句的返回值,判断是否返回无用的数据。此时说明索引不合理,进一步地,服务器还可以利用日志信息中包含的平均锁定时间、平均返回记录数、平均查询时间等参数计算索引命中率,当索引命中率高于或低于某个值时可以认为索引不合理。

具体实施时,服务器可以获取具体的业务sql(即日志信息),包括执行的查询条件和具体查询条件的值,索引信息、访问计数、锁定时间、返回记录、查询时间、平均锁定时间、平均返回记录数、平均查询时间等信息,并且获取当前业务操作的表(可能多个),把获取到的数据记录到静态文件中。并使用相应的指令对解析得到的语句进行分析。最后可以根据指令的执行计划以及业务表当前的索引信息计算使用当前索引的命中率并且将计算结果记录到文件中,便于后续对索引进行优化。

在一些实施例中,所述日志信息异常情况和错误原因的对照关系是研发人员根据经验获得的并写入服务器中的。

本实施例中,可以根据已采集的慢查询进程的日志信息,对日志信息中的参数进行判断,从中选择变现异常的参数,并根据这些异常的参数和预先存储的日志信息异常情况和错误原因的对照关系确定问题所在。后续步骤可以给人家问题选择优化方案进行优化

103:根据所述错误原因选择对应的优化方案进行优化。

本实施例中,在确定索引错误的原因后,服务器可以根据错误原因选择对应的优化方法对错误进行优化。其中,所述优化方案可以是研发人员预先写入配置文件的,也可以是研发人员实时添加到服务器中的。

具体地,服务器可以针对错误原因执行以下操作:

当错误原因为索引不存在时,可以扫描整个数据库后根据扫描结果创建索引,进一步地,当查询条件中出现运算或者函数嵌套的情况是,可以根据实际业务修改运算方式和嵌套函数。进一步提高的查询效率。

当错误原因为索引聚合时,可以根据具体的聚合索引,按照从右向左的顺序进行删除。

当错误原因为锁竞争时,可以根据进程池中其他查询进程进行分析。

当索引不合理时,可以调整索引中的语句进行优化。

进一步地,当上述方法执行后仍无法降低所述慢查询进程的执行时间时,可以删除索引并重建。

进一步地,当索引存在,并且命中率符合要求,此时可以认为数据库业务基本判定和索引无关,可能是由于数据库本身的默认配置或者所在节点的性能有关,此时需要研发人员手动调整默认配置或者完成物理硬件的升级,本申请不做进一步限定。

本实施例提供了一种索引自动优化方法。可以通过预设时间和指定的存储位置,从进程池中确定慢查询进程并实施采集其日志信息。并根据所述日志信息进行分析,确定错误原因。再根据所述错误原因选择对应的优化方案进行优化。可以实现数据库中索引的故障检测和自动优化,防止数据查询业务因索引的错误使用导致的性能降低。

图2为本申请一实施例提供的慢查询进程确认流程图,包括:

201:设定慢查询进程预设时间。

在例如mysql的数据库中,服务器本身具有日志记录的功能。在本实施例中,可以在服务器程序中添加例如long_query_time的参数设定预设时间。此时,服务器可以将执行时间超过所述预设时间的进程视为慢查询进程。

202:实时记录查询进程执行时间。

203:根据所述执行时间从进程池中选择执行时间超过预设时间的慢查询进程。

在本实施例中,服务器可以实时对全部查询进程的执行时间进行监控记录,并从中选择执行时间超过预定事件的进程作为慢查询进程,实现对进程的实时监控,进一步实现索引的自动优化。

进一步地,本申请提供的索引自动优化方法可以在服务器中进行迭代循环。服务器可以持续地对进程的执行时间进行监控,并根据预设时间判断进程是否为慢查询进程。当出现慢查询进程时,可以自动采集慢查询的日志信息并根据所述日志信息分析错误原因,选择优化方案进行优化。在完成优化后,可以将所述慢查询进程进入下次迭代。也就是对优化后的进程继续进行监控,判断其执行时间是否超过预设时间。实现索引的自动优化。

为进一步对本申请提供的索引自动优化方法进行说明,图2提供了一种索引优化流程图,包括:

301:判断错误原因是否为全表扫描。

在一些应用场景下,服务器在对日志信息进行分析后,发现所述慢查询进程并未使用索引进行查询,而是直接对数据库进行了全表扫描。此时可能的原因为:未创建索引、在索引列表嵌套了函数或者逻辑运算导致索引失效、索引顺序使用错误等。此时可以分别采用根据查询条件创建索引、修改查询逻辑保障索引生效、针对sql语句进行优化等方案。

302:判断错误原因是否为索引执行时间过长。

在一些应用场景下,服务器在对日志信息进行分析后,发现所述慢查询进程虽然使用了索引,但是仍存在查找时间过长的问题。此时可以认为服务器中的部分查询语句异常,导致索引顺序异常。服务器可以采用调整索引的顺序设配排序和分组顺序进行优化。

当服务器已采用上述方案对索引进行优化后,进程的执行时间并未出现明显改善时,可以认为是索引碎片太多切不具有连续性导致的。在数据库需要删除其中存储的一些数据时,索引也会做相应的调整。删除后的索引会产生空洞,影响查询速度。此时服务器可以直接删除现有索引,对索引进行重建,获得连续的、正常的索引。

303:判断错误原因是否为索引聚合。

在一些应用场景下,慢查询进程出现的原因可以是索引聚合。此时索引出现冗余,可以通过删除不需要的索引提高内存使用。

本实施例提供了一种索引自动优化的流程图。在数据库实际运行时,慢查询进程的出现可能有很多种原因。由于系统本身不具有类似研发人员的学习和分析能力,可以按照本实施例提供的流程图根据日志信息和错误原因逐步对索引进行优化。

进一步地,本申请实施例中可以将优化后的进程迭代进入下一个优化流程,也就是重新进行执行时间监控和日志采集。当进程在下一个检测周期内执行时间低于预设时间,可以认为该进程及对应的索引已优化完毕。当进程仍为慢查询进程且根据日志信息分析得到的错误原因和第一次优化一致时,可以认为对索引的优化是无效的,服务器删除索引并重建。通过优化方法的不断迭代,实现索引的自动优化。

图4为本申请一实施例提供的索引自动优化装置图,包括:

401:日志记录单元,用于记录慢查询进程的日志信息。

402:日志分析单元,用于对所述慢查询进程日志信息进行分析,确定错误原因。

403:优化单元,用于根据错误原因选择优化方案进行优化。

在本实施例中,所述日志记录单元可以用于记录慢查询进程的日志信息;所述日志分析单元可以用于对实时慢查询进程的日志信息进行分析并确定错误原因;所述优化单元可以根据错误原因选择优化方案进行优化,实现索引的自动优化。

进一步地,所述优化单元在对索引进行优化后,还可以向所述日志记录单元发送指令,重新对使用优化后索引的进程进行日志信息的采集记录。通过对所述使用优化后的查询进程的执行时间进行判断,实现对慢查询进程及错误索引的实时监控和自动优化。

在一个实施例中,所述日志记录单元包括:

时间设定单元,用于获取并设定预设时间

进程监控单元,用于记录查询进程执行时间;

比较单元,用于根据所述执行时间判断所述进程是否为慢查询进程;

日志输出单元,用于将所述慢查询进程的日志信息输出至指定路径。

在本实施例中,所述时间设定单元可以用于获取定设定预设时间;所述进程监控单元可以用于记录查询进程的执行时间;所述比较单元可以用于根据所述执行时间判断所述进程是否为慢查询进程。具体地,所述时间设定单元可以获取用户设定的预设时间。所述进程监控单元可以对进程池中全部查询进程进行监控,并记录每个进程的执行时间。所述比较单元可以将获取到的进程执行时间和预设时间进行比较,判断查询进程的执行时间是否超过预设时间。当检测到进程池中的某个进程的执行时间超过预设时间时,可以认为该进程为慢查询。通知日志输出单元,将该慢查询进程的日志信息输出到研发人员指定的存储位置。

在一个实施例中,所述优化单元包括:

方案选择单元,用于根据错误原因选择对应的优化方案;

优化方案执行单元,用于执行所述优化方案。

本申请实施例中提到的“第一用户”、“第二用户”等名称中的“第一”只是用来做名字标识,并不代表顺序上的第一、第二。

通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到上述实施例方法中的全部或部分步骤可借助软件加通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如只读存储器(英文:read-onlymemory,rom)/ram、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者诸如路由器等网络通信设备)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的,其中第一用户和第二用户可以是或者也可以不是物理上分开的,作为初始任务模板的部件可以是或者也可以不是代码模板。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。

以上所述仅是本申请示例性的实施方式,并非用于限定本申请的保护范围。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1