CN104714984A

CN104714984A - 一种数据库优化的方法和装置

Info

Publication number: CN104714984A
Application number: CN201310698265.9A
Authority: CN
Inventors: 郭远胜; 袁帅
Original assignee: China Mobile Group Hunan Co Ltd
Current assignee: China Mobile Group Henan Co Ltd; China Mobile Group Hunan Co Ltd
Priority date: 2013-12-17
Filing date: 2013-12-17
Publication date: 2015-06-17

Abstract

本发明公开了一种数据库优化的方法，接收索引优化配置指令，根据接收到的索引优化配置指令配置数据库中需要监控索引的数据表信息；创建索引优化任务，并对所述索引优化任务进行监控，获得对应数据表信息的SQL执行信息；分析采集到的所述SQL执行信息，计算得到最优索引方案；本发明同时还公开了一种数据库优化的装置。

Description

一种数据库优化的方法和装置

技术领域

本发明涉及移动通信中的数据库管理技术，尤其涉及一种数据库优化的方法及装置。

背景技术

数据库（Database）是按照数据结构来组织、存储和管理数据的仓库，一个技术框架固定、数据库架构稳定的业务系统，其运行性能的好坏绝大部分取决于数据库的性能变化，而一套整体合理的索引方案对数据库的稳定及性能提升起着至关重要的作用。

所谓索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可以快速访问数据库表中的特定信息。在ORACLE数据库中，索引存储有两部分的信息：表中的列值和相应的行标识（rowid）；其中，rowid包含数据行的物理地址，可唯一标识一行记录。在合适的列上使用索引，有可能仅通过一个或少量几个磁盘读取就能找到表中某个块的具体位置，快速获取到所需要的数据。但如果在不合适的列上使用索引，那么，必须从索引中进行多次检索，得出所有的rowid，然后再通过rowid从数据库表中读取同样多的次数，才能获取到所需要的数据，这样，使用索引查询反而比不使用索引更慢，数据检索效率更低。

另外，索引本身存在维护代价。对于数据库中频繁插入、删除的表，如果创建较多的索引，或者在经常进行更新操作的字段上创建索引，索引的维护会影响这些数据操纵语言（DML）操作如插入、删除、更新等操作的效率；因此，需要在完成查询操作、DML操作的同时，兼顾考虑保证索引的合理性。

发明内容

有鉴于此，本发明实施例提供了一种数据库优化的方法和装置，能实现索引的自动提前预警，剔除不合理的索引，简化索引方案，保证索引的合理性。

本发明的技术方案是这样实现的：

本发明实施例提供了一种数据库优化的方法，该方法包括：

接收索引优化配置指令，根据接收到的索引优化配置指令配置数据库中需要监控索引的数据表信息；

创建索引优化任务，并对所述索引优化任务进行监控，获得对应数据表信息的SQL执行信息；

分析采集到的所述SQL执行信息，计算得到最优的索引方案。

上述方案中，所述SQL执行信息包括SQL语句、SQL执行频率和调用的谓词信息。

上述方案中，在创建索引优化任务之前，所述方法还包括：通过查询任务调配库，判断配置的数据表信息是否是重复执行，当重复执行时，跳过所述数据表信息；当单次执行时，索引优化任务创建完成。

上述方案中，所述对所述索引优化任务进行监控，包括：

确定创建的监控任务的连接信息，根据确定出的连接信息，连接目标数据库；

接收目标数据库后反馈的响应信息，根据响应信息确定连接成功；

按照创建的监控任务，从连接的目标数据中获得与监控任务对应的SQL执行信息；

在得到的SQL执行信息中确定获得的数据表的行数；

在获得的信息中，根据SQL执行信息的SQL_ID分别取ACCESS谓词和FILTER谓词；

根据获得的谓词统计SQL执行信息的执行频率。

上述方案中，所述分析采集到的SQL执行信息，计算得到最优的索引方案，包括：

根据信息采集库中获得的SQL执行信息，分析与数据表信息相关的所有SQL语句中谓词的使用规律、谓词组合程度；

根据SQL中谓词的使用规律、谓词组合程度的计算结果，进行复合索引评估；

根据复合索引评估结果，创建复合索引；

迭代分析谓词，直至结束，得到最优的索引优化方案。

本发明还提供了一种数据库优化的装置，该装置包括：索引优化配置模块、任务监控模块、信息采集模块和分析模块；其中，

索引优化配置模块，用于接收索引优化配置指令，根据接收到的索引优化配置指令配置数据库中需要监控索引的数据表信息；还用于创建索引优化任务；

任务监控模块，用于对所述索引优化任务进行监控，获得对应数据表信息的SQL执行信息；

信息采集模块，用于在目标数据库中采集创建的任务对应数据表信息的SQL执行信息；

分析模块，用于根据所述信息采集模块采集到的所述SQL执行信息计算最优索引方案。

上述方案中，所述任务监控模块，还用于确定创建的监控任务的连接信息，根据确定出的连接信息，连接目标数据库；在连接的目标数据中获得与监控任务对应的SQL执行信息；根据SQL执行信息的SQL_ID分别取ACCESS谓词和FILTER谓词；根据获得的谓词统计SQL执行信息的执行频率。

上述方案中，所述信息采集模块，还用于根据信息采集库中采集到的SQL执行信息，分析与数据表信息相关的所有SQL语句中谓词的使用规律、谓词组合程度。

上述方案中，所述分析模块，还用于根据SQL中谓词的使用规律、谓词组合程度的计算结果，进行复合索引评估；根据复合索引评估结果，创建复合索引；迭代分析谓词，直至结束，得到最优的索引优化方案。

本发明实施例所提供的数据库优化的方法和装置，接收索引优化配置指令，根据接收到的索引优化配置指令配置数据库中需要监控索引的数据表信息；创建索引优化任务，并对所述索引优化任务进行监控，获得对应数据表信息的SQL执行信息；分析采集到的SQL执行信息，计算得到最优的索引方案；如此，能从数据库全局出发，提出整体的索引最优方案，实现索引自动提前预警，有效避免原来的性能问题发生后再分析索引方案的状况发生，删除或合并不合理的索引，以保证索引方案的精简，为用户带来更好的体验。

附图说明

图1为现有技术中数据库索引优化方法的处理流程示意图；

图2为本发明实施例数据库优化方法的处理流程示意图；

图3为本发明实施例中一种对数据库优化时监控创建任务和采集信息的处理流程示意图；

图4为本发明实施例最优索引方法的处理流程示意图；

图5为本发明实施例数据库索引装置的组成结构示意图。

具体实施方式

为了更好的理解本发明，先介绍下目前对数据库索引的优化方法，如图1所示，目前数据库索引优化方法的处理流程包括以下步骤：

步骤110：实时监控数据库等待事件，判断是否有异常等待发生；

这里，如果有异常等待发生，说明存在低效结构化查询语言（SQL，StructuredQuery Language）；

步骤111：根据数据库诊断报告检测，判断是否有资源消耗比较突出的TOPSQL；

这里，如果存在资源消耗比较突出的TOP SQL，说明存在低效SQL；

上述步骤110、步骤111可以同时执行，也可以单独执行。

步骤112：如果根据步骤110或步骤111的判断发现存在低效SQL，则手工或使用Oracle SQL tuning advisor工具分析SQL及相关联的业务表和索引分布情况，确定是否需要创建合适的索引来提升SQL效率；

步骤113：根据预设的索引优化方案，创建合适的索引；

这里，所述创建合适的索引包括：新增索引或修改现有索引；

步骤114：让SQL原来的执行计划失效，并重新生成执行计划；

步骤115～117：查看该SQL新的执行计划、相应cost开销、以及等待事件，验证问题是否解决，如果没有解决，则进行迭代分析，直至问题解决。

但是，图1所述的数据库索引的优化方法存在以下问题：

1）不具备预见性。上述解决方案对索引进行优化时，是在数据库索引性能问题出现之后，开始对索引进行优化，但此时数据库的使用已经受到影响。

2）缺乏全局考虑，局限性较强。上述解决方案对索引进行优化时，技术人员定位到具体的SQL语句，只针对该单一SQL语句进行分析，在该SQL语句相关的表和字段上制定索引优化方案，未能全面考虑到该索引变更对同样的表上其它SQL的性能影响。

3）索引只增不减，降低数据库的查询效率。上述解决方案对索引进行优化时，因担心由于删除、合并索引会有较大可能影响到其它SQL的性能，一般从最小影响考虑，因此，对索引进行优化时，仅在原有索引基础上增加所需索引，这样，就会导致整个数据库的索引方案越来越庞大、越来越复杂，甚至会反过来降低数据库的效率。

可见，上述对数据库索引进行优化的方法，不具有预见性，缺乏全局考虑，且对数据库的资源消耗过大，对数据库的优化有一定的限制。

基于此，在本发明实施例中，接收索引优化配置指令，根据接收到的索引优化配置指令配置数据库中需要监控索引的数据表信息；创建索引优化任务，并对所述索引优化任务进行监控，获得对应数据表信息的SQL执行信息；分析采集到的SQL执行信息，计算得到最优的索引方案。

为了使本发明的目的、技术方案和优点更加清楚，下面通过附图及具体实施例对本发明做进一步的详细说明。

本发明提供了一种数据库优化的方法，如图2所示，该方法包括以下步骤：

步骤210：接收索引优化配置指令，根据接收到的索引优化配置指令配置数据库中需要监控索引的数据表信息；

其中，所述数据表信息包括数据表、或数据表的集合；

在本步骤中，数据库接收索引优化配置指令，索引优化配置指令可以包括任务的创建、更新、删除、查询和调度等操作；

这里，由数据库管理员配置写配置文件，写配置文件中包括要优化的数据库中数据表信息，比如用户名、表名等；根据接收到的索引优化命令配置数据库中需要监控索引的数据表信息；其中，索引优化配置指令中可以设置执行单次操作，还是循环执行多次，比如：可以根据索引配置指令创建一个数据表，也可以是循环创建多个数据表。

步骤220：创建索引优化任务；

具体的，所创建的任务会存储在任务调配库中，一般，已执行的索引优化配置指令会在任务调配库中留有日志，相应的，通过查询任务调配库，就可以判断配置的数据表信息是否是重复执行，如果是重复执行，则跳过该数据表信息，当单次执行索引优化配置指令的操作后，索引优化任务创建完成。

这里，一个数据表可以有多个索引，但一个索引只能在一个数据表中。

其中，在每次进行创建索引优化任务时，创建的索引优化任务需要在任务调配库中存储一份，所以任务调配库是不断更新的；

例如，根据索引配置指令删除某个数据表集合的其中一个数据表时，在任务调配库里会删除这个数据表的信息，但是会留有删除操作的日志；如果索引配置指令操作是执行一次，在数据表集合中删除这个数据表后，任务调配库进行一次更新，索引优化任务创建完成；其中，创建的索引优化任务中包含用户名/表名集合、采样的起止时间、采集的频率等信息。

步骤230：索引优化任务创建完成后，由监控任务对应的进程对所创建的索引优化任务进行监控，从连接的目标数据库中获得与监控任务对应的SQL执行信息，并记录获得的SQL执行信息；

这里，所述获得的SQL执行信息记录到信息采集库中；所述由监控任务对应的进程监控创建的索引优化任务，可以是监控创建的索引优化任务中的用户名/表名集合、采样的起止时间，采集的频率等信息，也可以是监控创建的索引优化任务的连接信息，如IP端口、数据库的服务名称等，从而能实时掌握创建的任务中的数据表执行的状态和结果。

在实际应用中，移动终端的目标数据库上开放有一个端口作为服务端口，用来接收任务调配库的请求，比如：可以是1521端口但不限于此，通过服务端口由任务调配库中配置的任务定时连接到目标数据库，在目标数据库中存储有移动终端的信息，比如：用户的消费记录、用户的个人资料等；连接到目标数据库的周期可根据需要由管理员设置，通常默认为一小时一次。

在目标数据库中，根据监控创建的索引优化任务的数据表信息，找到对应的、在目标数据库中运行的SQL执行信息，进而确定创建的索引优化任务对应的数据表信息的所有SQL语句、SQL执行频率和调用的谓词信息等SQL执行信息，并记录到信息采集库中。

其中，ORACLE数据库中的谓词，是指在SQL的WHERE条件中存在的键值对应的键；例如，“select user_name from users where user_id=1234andexpire_time>sysdate”中user_id和expire_time均为谓词，也可理解为被where条件使用的表的部分字段；将这些谓词信息记录到信息采集库中。

图3示出了步骤230的具体处理过程，包括以下步骤：

步骤2301：索引优化任务创建完成后，确定创建的监控任务的连接信息，根据确定出的连接信息，连接目标数据库；

在索引优化任务创建之后，监控任务对应的进程对目标数据库中创建的索引优化任务进行监控，用户根据目标服务器的IP、监听端口和服务器名称确定创建的监控任务的连接信息，在目标数据库上开放有一个端口作为服务端口，用来接收任务调配库的请求，根据连接信息确定任务调配库中哪些数据表需要连接到目标数据库，以便在目标数据库中获得对应的数据表中的SQL语句、SQL的执行频率、调用的谓词信息等SQL执行信息；

其中，对创建的索引优化任务进行监控时，如果配置成单次，在得到单次的运行结果后，输出本次索引优化结果；

步骤2302：接收目标数据库反馈的响应信息，根据响应信息确定连接成功时，继续步骤2303；确定连接失败时，返回步骤2301；

这里，目标数据库收到任务分配库基于连接信息的请求后，会向任务调配库发出反馈的响应信息。

步骤2303：与目标数据库连接成功后，按照创建的监控索引优化任务，从连接的目标数据库中获得与监控任务对应的SQL执行信息；

目标数据库向任务调配库反馈连接成功的响应后，可以根据创建的监控索引优化任务中的用户名/表名集合、采样的起止时间、采集的频率等，从连接的目标数据库中获得与监控任务对应的SQL执行信息；例如：可以根据用户名/表名集合从连接的目标数据库中得到相关SQL、以及SQL_ID唯一标识，记录在信息采集库中；

步骤2304：在得到的SQL执行信息中确定获得的数据表的行数；

从目标数据库中获得与监控任务对应的SQL执行信息，根据获得的SQL执行信息确定获得的数据表的行数；若获得的数据表的行数大于预先设置的阈值，执行步骤2305，否则，不需要进行索引创建；

这里，之所以考虑数据表行数不大于阈值时不进行索引创建，是因为创建索引会额外给数据表的一些更新、插入和删除动作带来开销，同时还对索引进行维护，因此通过索引查找数据是需要代价的，在获得的信息库的行数较少时，创建索引是没有必要的，例如：少于10000行的业务表，则不进行创建索引；

其中，所述预设阈值的大小可以由数据表的信息量决定，通常，数据表创建索引的密度主要是根据数据表的行数决定的，密度取值为1-6左右，在一个数据库中，阈值的大小不是固定不变的，可以通过对数据库综合评估，根据实际情况适时调整阈值；

步骤2305：在获得的信息中，根据SQL执行信息的SQL_ID分别取ACCESS谓词和FILTER谓词；

其中，谓词的信息包括ACCESS谓词和FILTER谓词，FILTER是某SQL中目前未能使用上索引的谓词，ACCESS则是某SQL中目前已使用上索引的谓词，但是，目前已使用上索引的谓词未必是全局最优的，而适合创建索引的谓词在优化前可能没有被创建索引利用，因此，在获取的信息中，要根据SQL执行信息的SQL_ID分别取ACCESS谓词和FILTER谓词；

具体的，在获取谓词的时候，可能包含下述几种情况：

第一种情况：如果获得的谓词中包含第一关键字和/或第二关键字，则需要将第一关键字和/或第二关键字左右分别进行拆分，将包含第一关键字和/或第二关键字的一个谓词拆分为两个独立的谓词，以便计算谓词的选择性和谓词的频率。第一关键词和第二关键词可以是“and”、“or”等；

例如：某个谓词为“user_id=1and user_name=john”，拆分为“user_id=1”和“user_name=john”，以方便后续计算谓词的选择性和谓词的频次；

第二种情况：有些采集到的字段是无法使用索引的，因此，在采集的过程中需要将无法使用索引的字段进行过滤；

例如：like中的前缀为“%”、“IS NULL”、“IS NOT NULL”、“<>”、“！=”、“NOT IN”、“NOT LIKE”，这些谓词不能使用索引，不在本发明的分析之列，需要对这些谓词进行过滤；

第三种情况：在获得谓词时，如果谓词中包含函数，则需要建立基于函数的索引；

具体的，在获得的谓词中，当谓词上有函数时，直接在函数上创建索引无法使用的，比如：存在TO_CHAR()（转换为字符串）、TO_NUMBER()（转换为数字）、SUBSTR()（截取字符串）、UPPER()（字符串转大写）、LOWER()（字符串转小写）和MAX()（取最大值等函数），必须创建基于函数的索引才能使用。

在本发明中，谓词的选择是重要的指标，对于低选择性的列，创建的索引是没有价值的，并且还可能会影响DML操作的效率，具体谓词的选择性将在步骤240中详细描述；

步骤2306，在获得谓词后，根据获得的谓词统计SQL语句的执行频率；

通过数据库的系统视图可以获得谓词的相关信息，根据获得的谓词的具体情况进行分析是否需要拆分、过滤等，并根据获得的谓词信息统计SQL的执行频率。

步骤240：分析采集到的SQL执行信息，计算得到最优的索引方案。

图4示出了计算得到最优索引方案的具体处理流程，具体为：

步骤2401：根据采集到的SQL执行信息，分析与数据表信息相关的所有SQL语句中谓词的使用规律、谓词组合程度；

根据信息采集库采集到的信息，如用户名/表名、谓词、SQL语句的执行频率和谓词的选择性等，分析与数据表信息相关的所有SQL中谓词的使用规律、谓词组合程度。例如：同一个SQL语句中含有多个数据表，而同一个数据表中的多个谓词又可以相互组合，谓词的组合程度越高，说明谓词出现的频率越高；在本发明中确定谓词的选择性和谓词的频率是判断一个谓词是否创建索引的关键；

其中，谓词的选择性，是指谓词中不同值的数据与数据表中记录数的比率。

如果一个数据表中的数据有100000行，谓词有85000个不同的值，那么选择性为：85000/100000=0.85，

由此看出，谓词的选择性取值大于等于0、小于等于1，越接近1，则选择性越好，索引的效率越高；具体的，可以采用公式（1）来表示：

Selectivity＝Dist/Rows （1）

其中，Selectivity表示选择性，Dist表示谓词的不同的值的总和，Rows表示表中数据的总行数；

另外，确定多谓词的选择性，在创建复合索引时，需要考虑多个谓词组合的选择性；具体的，可以采用下述公式（2）来表示：

Selectivities = 1 - (1 - \frac{{Dist}_{1}}{Rows}) \times (1 - \frac{{Dist}_{2}}{Rows}) \times . . . (1 - \frac{{Dist}_{n}}{Rows}) - - - (2)

其中，Selectivities表示多谓词选择性，Dist1表示谓词1的值的总和，Rows表示表中数据的总行数，n为自然数。依次类推，Dist2表示谓词2的值的总和；

例如，如果一个数据表中的数据有100000行，谓词1有80000个不同的值，谓词2有75000个不同的值，谓词3有70000个不同的值，那么多谓词的选择性为：

Selectivities=1-（1-80000/100000）×(1-75000/100000)×(1-70000/100000)

即：Selectivities=0.015；

确定谓词频率，谓词频率是指使用该谓词的所有SQL单位时间内平均执行频率之和；具体可以采用公式（3）来表示：

Exec_Freq=SQL-Freq₁+SQL-Freq₂+…SQL-Freq_n （3）

在公式（3）中，Exec_Freq表示谓词频率，SQL-Freq1表示谓词在SQL1中出现的频率，依次类推，SQL-Freq_n表示谓词在SQLn中出现的频率，n为自然数；

步骤2402，根据SQL中谓词的使用规律、谓词组合程度的计算结果，进行复合索引评估；

具体的，在进行复合评估时，将同一SQL中且频率排名靠前的谓词尝试进行组合，检查是否有其他SQL有相同或者部分相同谓词，索引能否重复利用，并评估代价。

这里，所述评估代价是评估数据库索引时系统的消耗，在创建索引时，数据表的插入、删除和修改等操作会产生系统消耗，维护索引又会产生额外的消耗，并且复合索引产生的消耗大于单列索引产生的消耗，但是，由于复合索引对出现的谓词进行组合，效率要比单利索引高，所以，在评估索引的代价时，要结合实际情况，计算相应的消耗，通过排序来确定最优的索引方案；

其中，将同一SQL语句中频率排名靠前的谓词尝试进行组合，检查是否与其他SQL有相同或者部分相同谓词，索引能否重复利用，从数据库全局出发，提出整体的索引最优方案，有效避免了原来的单个索引变更后引起新的性能问题风险；

对索引的评估要综合考虑谓词的选择性和谓词的频率，索引的评估值具体的可采用公式（4）计算：

V = \frac{{(Exec_Freq \times 10)}^{2}}{1 + \log_{0.5} Selectivities} - - - (4)

在上述公式（4）中，V表示评估值，Exec_Freq表示谓词频率，Selectibities表示单/多谓词选择性；

步骤2403，根据复合索引评估结果，确定创建复合索引；

对于低于单列索引，通过遍历排序评估索引利用率来决定字段顺序，考虑多个谓词组合的选择性、谓词频率，将同一SQL中且频率排名靠前的谓词尝试进行组合，检查是否有其他SQL有相同或者部分相同谓词，索引能否重复利用对谓词的组合的选择性进行排列；

例如，谓词AB、AC、BD，谓词A的频率比较高，将带有谓词A的组合排名靠前；再例如，一个电话薄中的人名由姓和名构成，电话薄首先按姓氏进行排序，然后按名字对其相同姓氏的人进行排序；如果知道姓，电话簿非常有用；如果知道姓和名，电话簿则更为有用，但如果只知道名不姓，电话簿的用处就不大了，所以对其进行复合索引时，将电话薄中的姓和名的谓词进行组合创建复合索引；

对于单列索引代价更低的索引，则考虑进行单列索引分析，不需要创建复合索引；首先，从目标数据库中统计所有SQL中各谓词字段调用频率，按调用谓词的频率从高到低排列，并算出各名次的频率差值，各名次的频率差值是与谓词使用的频率相减并降序排列得到的；其次分析谓词的选择性，谓词的选择性越高，说明在进行索引的时候更容易选定，例如用来表示性别的字段，只有两个值，选择性就很低，而用来标识个人身份的身份证字段，由18个数值构成，识别度高，一个身份证信息只能唯一识别一个人，说明选择性高；如果所述谓词的选择性低，同时所述谓词频率也低，把所述谓词丢弃即可；如果所述谓词的选择性低，但是所述谓词的频率高，建议采用人工判断位图索引（该选项可配置），跳到步骤2404；如果所述谓词选择性高，则需要判断在所述谓词上是否有函数，当所述谓词上存在函数时，建议创建基于函数的B树索引，当所述谓词上不存在函数时，建议采用创建B树索引，跳到步骤2404；

步骤2404，迭代分析谓词，直至结束，得到最优的索引优化方案；

这里，遍历数据库中采集到的谓词，并进行迭代分析，根据谓词的选择性、谓词的频率及评估代价综合分析，将计算得到的索引优化方案与现有的索引优化方案比较，输出索引优化（增加、删除、合并等）建议和预警建议，得到最优的索引优化方案；

具体的，例如：在数据库A中，原来b、c和d字段采用的是单列索引，而经过分析并评估代价，建议在a和bc上创建索引，那么，新增了a的索引，合并了bc索引，合并的bc索引为复合索引，删除了d上的索引；

由评估代价得到评估值与对应的阀值比较，确定是否需要在此谓词（或多个谓词）上创建索引（或复合索引）；每个业务数据库支撑的业务有差异，前端应用有差别，所以，数据库支撑的事务量、SQL的总量、SQL的执行频率等都不一样，所以评估值对应的阀值不是适合所有数据库的一个常量，而是每个数据库均有自己对应的一个阀值，这个阀值的制定需要通过对全库索引评估值、数据库原有索引吻合度综合分析，一般在初次全库索引优化分析中确定的(后期也可以根据实际情况调整)，当该阀值确定后，即可用于后续的数据库索引方案全局优化及自动预警；

例如，当阈值为10000时，对于当前的数据库来说是合适的，后续在数据库稳定运行时，该阈值持续有效，当得到的评估值低于阈值时，说明当前的索引方案已经不是最优的了，终端的后台服务器给出警示，比如以短信的形式告知用户，或是在任务调配库中给出预警提示。

本发明提供了一种数据库优化的装置，如图5所示，包括索引优化配置模块41、任务监控模块42、信息采集模块43和分析模块44。

索引优化配置模块41，用于接收索引优化配置指令，根据接收到的索引优化配置指令配置数据库中需要监控索引的数据表信息；还用于创建索引优化任务；

其中，所述数据表信息包括数据表、或数据表的集合；

所述索引优化配置指令可以包括任务的创建、更新、删除、查询和调度等操作；这里，可由数据库管理员配置写配置文件，写配置文件中包括：要优化的数据库中数据表的信息（比如用户名、表名等），根据接收到的索引优化命令配置数据库中需要监控索引的数据表信息；其中，索引优化配置指令中可以定义是执行单次操作，还可以是循环执行多次；

所述索引优化配置模块41进一步包括任务调配库，在每次进行创建索引优化任务时，创建的索引优化任务要在任务调配库中存储一份；

所述任务调配库是不断更新的，已执行的索引优化配置指令会在任务调配库中会留有日志；相应的，通过查询任务调配库，就可以判断配置的数据表信息是否是重复执行，如果是重复执行，则跳过该数据表信息，否则，索引优化任务创建完成，配置好的优化任务由任务监控模块42进行监控；

任务监控模块42，用于对索引优化配置模块41中创建的索引优化任务监控，从连接的目标数据中获得与监控任务对应的SQL执行信息，将信息记录到信息采集模块43中；

具体的，任务监控模块42可以是监控创建索引优化任务中的用户名/表名集合、采样的起止时间，采集的频率等信息，也可以是监控索引优化任务的连接信息，如IP端口、数据库的服务名称等，从而能实时掌握创建的任务中的数据表执行的状态和结果；

在目标数据库上开放有一个端口作为服务端口，用来接收任务调配库的请求，比如：可以是1521端口但不限于此，通过服务端口由任务调配库中配置的任务定时连接到目标数据库，在目标数据库中存储有移动终端的信息，比如：用户的消费记录、用户的个人资料等；连接到目标数据库的周期可根据需要由管理员来设置，通常默认为一小时一次；

在目标数据库中，根据监控创建的索引优化任务的数据表信息找到对应的、在目标数据库中运行的SQL执行信息，进而确定创建的任务对应的数据表信息的所有SQL语句、SQL执行频率、调用的谓词信息等SQL执行信息，并记录到信息采集模块43中；

其中，ORACLE数据库中的谓词，是指在SQL的WHERE条件中存在的键值对应的键；例如“select user_name from users where user_id=1234andexpire_time>sysdate”中user_id和expire_time均为谓词，也可理解为被where条件使用的表的部分字段；

任务监控模块42还用于确定创建的监控索引优化任务的连接信息，根据确定出的连接信息，连接目标数据库；

具体的，任务监控模块42对数据库中创建的索引优化任务进行监控，用户根据IP端口或数据库的服务名称确定创建的监控任务的连接信息，在目标数据库上开放有一个端口作为服务端口，用来接收任务调配库的请求，根据连接信息确定任务调配库中哪些数据表需要连接到目标数据库，以便在目标数据库中获得对应的数据表中的SQL语句、SQL的执行频率、调用的谓词信息等信息。监控模块42对创建的任务进行监控时，如果配置成单次，在得到单次的运行结果后，输出本次索引优化结果；

任务监控模块42还用于接收连接目标数据库后反馈的响应信息，根据响应信息判断是否连接成功；

具体为，目标数据库收到连接信息的请求后，向任务调配库发出反馈响应信息，根据响应的信息判断是否连接成功，如果连接成功，从目标数据库中获得与任务监控模块42监控的数据表对应的SQL执行信息，如果连接失败，根据连接信息继续连接目标数据库。

任务监控模块42还用于与连接目标数据库成功后，按照监控的创建索引优化任务，从连接的目标数据中获得与监控任务对应的SQL执行信息；

具体的，目标数据库向任务调配库反馈连接成功的响应后，可以根据创建的监控索引优化任务中的用户名/表名集合、采样的起止时间，采集的频率等在连接的目标数据库中获得与监控任务对应的SQL执行信息，记录在信息采集模块43中；

任务监控模块42还用于在得到的SQL执行信息中确定获得的数据表的行数；

具体的，在目标数据库中获得与监控任务对应的SQL执行信息后，根据获得的SQL执行信息中确定获得的数据表的行数；若获得的数据表的行数大于预先设置的阈值，需要创建索引，否则，不需要进行索引创建；创建索引会额外给数据表的一些更新、插入和删除动作带来开销，同时还对索引进行维护，因此通过索引查找数据是需要代价的，在获得的信息库的行数较少时，创建索引是没有必要的，例如少于10000行的业务表，则不进行创建索引；

任务监控模块42还用于在获得的信息中，根据SQL执行信息的SQL_ID分别取ACCESS谓词和FILTER谓词；

任务监控模块42用于在获得谓词后，根据获得的谓词统计SQL执行信息的执行频率；

具体的，通过数据库的系统视图可以获得谓词的相关信息，根据获得的谓词的具体情况进行分析是否需要拆分、过滤等，并根据获得的谓词信息统计SQL的执行频率；

信息采集模块43，用于在目标数据库中采集创建的索引优化任务对应数据表信息的SQL执行信息；

信息采集模块43还用于根据信息采集库中获得的信息，分析与数据表相关的所有SQL语句中谓词的使用规律、谓词组合程度；

具体的，信息采集模块43根据信息采集库采集到的信息，如用户名/表名、谓词、SQL的执行频率和谓词的选择性等，分析与数据表信息相关的所有SQL语句中谓词的使用规律、谓词组合程度；同一个SQL中含有多个谓词，而同一个数据表中的多个谓词又可以相互组合，谓词的组合程度越高，说明谓词出现的频率越高；在本发明中确定谓词的选择性和谓词的频率是判断一个谓词是否创建索引的关键；

分析模块44，用于分析采集到的SQL执行信息，计算得到最优的索引方案；

这里，分析模块44可以根据信息采集模块43采集到SQL中谓词的使用规律、谓词组合程度的计算结果，对数据库进行复合评估；具体的，可将同一SQL中且频率排名靠前的谓词尝试进行组合，检查是否有其他SQL有相同或者部分相同谓词，索引能否重复利用，并评估代价。

其中，所述评估代价是评估数据库索引时系统的消耗，在创建索引时，数据表的插入、删除和修改等操作会产生系统消耗，维护索引又会产生额外的消耗，并且复合索引产生的消耗大于单列索引产生的消耗，但是，由于复合索引对出现的谓词进行组合，效率要比单利索引高，所以，在评估索引的代价时，要结合实际情况，计算相应的消耗，通过排序来确定最优的索引方案。

其中，将同一SQL中且频率排名靠前的谓词尝试进行组合，检查是否有其他SQL有相同或者部分相同谓词，索引能否重复利用，从数据库全局出发，提出整体的索引最优方案，有效避免了原来的单个索引变更后引起新的性能问题风险。

分析模块44，还用于根据复合索引评估结果，判断是否创建复合索引；

具体的，对于低于单列索引，可以通过遍历排序评估索引利用率来决定字段顺序，需要考虑多个谓词组合的选择性、谓词频率，将同一SQL中且频率排名靠前的谓词尝试进行组合，检查是否有其他SQL有相同或者部分相同谓词，索引能否重复利用对谓词的组合的选择性进行排列。

例如，谓词AB、AC、BD，谓词A的频率比较高，将带有谓词A的组合排名靠前；再例如，一个电话薄中的人名由姓和名构成，电话薄首先按姓氏进行排序，然后按名字对其相同姓氏的人进行排序。如果知道姓，电话簿非常有用；如果知道姓和名，电话簿则更为有用，但如果只知道名不姓，电话簿的用处就不大了，所以对其进行复合索引时，将电话薄中的姓和名的谓词进行组合创建复合索引。

对于单列索引代价更低的索引，则考虑进行单列索引分析，不需要创建复合索引。首先，从目标数据库中统计所有SQL中各谓词字段调用频率，按调用谓词的频率从高到低排列，并算出各名次的频率差值，各名次的频率差值是与谓词使用的频率相减并降序排列得到的。

其次分析谓词的选择性，谓词的选择性越高，说明在进行索引的时候更容易选定，如果谓词的选择性低，同时谓词的频率也低，把所述谓词丢弃；如果谓词的选择性低，但谓词的频率高，建议采用人工判断位图索引（该选项可配置）；如果所述谓词选择性高，则需要判断在所述谓词上是否有函数，当所述谓词上存在函数时，建议创建基于函数的B树索引，当所述谓词上不存在函数时，建议采用创建B树索引。

分析模块44，还用于对根据采集到的SQL执行信息对谓词迭代分析，直至结束，得到最优的索引优化方案；

具体的，分析模块44遍历数据库中采集到的谓词，并进行迭代分析，根据谓词的选择性、谓词的频率及评估代价综合分析，将计算得到的索引优化方案与现有的索引优化方案比较，输出索引优化（增加、删除、合并等）建议和预警建议，得到最优的索引优化方案。

本发明实现索引自动提前预警，还可以定制循环执行的定时任务，通过数据采集和分析来捕捉客观变化，顺应业务的发展变化，自动提前发出索引预警信号，可有效避免原来的性能问题发生后再分析索引方案的状况发生。

通过本发明的方案，前期根据实际数据采集和分析，对上线前初始的索引方案进行了优化，后期通过定制索引自动预警任务，不断修正。数据库只保留合适的索引，不合理的索引则被删除或合并，保证数据库整体索引方案的精简。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims

1.一种数据库优化的方法，其特征在于，所述方法包括：

分析采集到的所述SQL执行信息，计算得到最优的索引方案。

2.根据权利要求1所述的方法，其特征在于，所述SQL执行信息包括SQL语句、SQL执行频率和调用的谓词信息。

3.根据权利要求1所述的方法，其特征在于，在创建索引优化任务之前，所述方法还包括：通过查询任务调配库，判断配置的数据表信息是否是重复执行，当重复执行时，跳过所述数据表信息；当单次执行时，索引优化任务创建完成。

4.根据权利要求1所述的方法，其特征在于，所述对所述索引优化任务进行监控，包括：

在得到的SQL执行信息中确定获得的数据表的行数；

根据获得的谓词统计SQL执行信息的执行频率。

5.根据权利要求1所述的方法，其特征在于，所述分析采集到的SQL执行信息，计算得到最优的索引方案，包括：

根据复合索引评估结果，创建复合索引；

迭代分析谓词，直至结束，得到最优的索引优化方案。

6.一种数据库优化的装置，其特征在于，所述装置包括：索引优化配置模块、任务监控模块、信息采集模块和分析模块；其中，

7.根据权利要求6所述的装置，其特征在于，所述SQL执行信息包括SQL语句、SQL执行频率和调用的谓词信息。

8.根据权利要求6所述的装置，其特征在于，所述任务监控模块，还用于确定创建的监控任务的连接信息，根据确定出的连接信息，连接目标数据库；在连接的目标数据中获得与监控任务对应的SQL执行信息；根据SQL执行信息的SQL_ID分别取ACCESS谓词和FILTER谓词；根据获得的谓词统计SQL执行信息的执行频率。

9.根据权利要求6所述的装置，其特征在于，所述信息采集模块，还用于根据信息采集库中采集到的SQL执行信息，分析与数据表信息相关的所有SQL语句中谓词的使用规律、谓词组合程度。

10.根据权利要求6所述的装置，其特征在于，所述分析模块，还用于根据SQL中谓词的使用规律、谓词组合程度的计算结果，进行复合索引评估；根据复合索引评估结果，创建复合索引；迭代分析谓词，直至结束，得到最优的索引优化方案。