CN103714058A - 数据库查询的优化 - Google Patents

Abstract

提供一种用于便利优化数据库查询的技术。在一些实施方式中，接收第一查询，通过在该查询中检测指定语法来自动地识别用于优化的至少一个场景，然后通过使用与该识别场景对应的预定义的操作来重写第一查询以自动地生成第二查询。

Description

数据库查询的优化

技术领域

本公开一般涉及数据库，更具体地，涉及数据库查询优化。

背景技术

数据库通常包括用于存储数据值的一个或多个数据库表格。为了在数据库中检索和操纵数据，用户、应用程序或远程系统通常向数据库管理系统(DBMS)发出数据库查询。数据库查询是指用于检索存储在数据库中的数据的语句、命令或子句的集合。例如，查询可以在数据库中指定检索数据的特定位置(例如，表格、行或列)，或者指定如何联接来自多个表格的列。

在运行之前编译查询。在编译期间，DBMS通常将该查询解析成为指定如何实现查询的关系运算符。可以在“查询计划”或“访问计划”中对关系运算符排序。因为通常存在具有性能变化很大的、大量可供选择的方法来运行给定查询，所以DBMS的查询优化器可以估计一些不同的可能计划并返回它认为的最佳查询计划。

因为查询优化器是非理想的，所以数据库用户和管理员有时需要人工地检查并调节查询计划以实现更好的性能。通常提供工具的集合(例如IBM图形化解释（Visual Explain）)来显示查询访问计划。一些数据库提供功能″EXPLAIN PLAN（解释计划）″以允许用户预览和估计由DBMS生成的查询计划。还可以提供返回用于运行查询的成本和时间的“计划表”。

然而，EXPLAIN PLAN功能在性能调节方面不是非常有用。例如，一些数据库可以返回具有许多未知结果(例如，运行时间)的计划表，使得难以判断哪个查询语句产生最有效的查询计划。此外，不同的“联接”序列会产生导致不同的运行次数的不同的查询计划，该运行时间经常是未知的。

此外，人工操纵性能调节会非常耗时和困难。复杂结构化查询语言(SQL)查询会需要执行不同的调节方法。在数据量改变的可能事件中，将必须重复全部冗长的调节处理以估计性能变化。此外，不同的数据库具有不同的特性，并且程序员必须熟悉下层数据库的特定特性以便执行性能调节。

因此，存在对解决上述挑战的、改善的数据库查询优化框架的需要。

发明内容

此处描述一种用于便于优化数据库查询的计算机实现技术。在一些实现中，接收第一查询。通过在第一查询中检测指定语法来自动地识别用于优化的至少一个场景。然后通过使用与识别的场景对应的预定义的操作重写第一查询来自动地生成第二查询。

利用将在下文中变得清楚的这些和其它优点与特征，通过参照以下详细描述和权利要求与附图，可以获得进一步信息。

附图说明

在附图中示出一些实施例，在附图中相同的参考标号标明相似的部分，其中：

图1是示出示范性系统的框图；

图2是示出通过示范性数据库管理系统的查询流的框图；

图3示出用于优化数据库查询的示范性方法；

图4示出示范性预定义场景和子场景；以及

图5示出示范性用户界面。

具体实施方式

在下面的描述中，为了说明的目的，阐述指定数目、材料和配置以便提供给出的框架和方法的彻底理解，以及以便满足法定的书写描述、实现和最佳的模式要求。然而，本领域技术人员清楚地是，可以在没有指定示范性细节的情况下实现给出的框架和方法。在其他情况中，省略或简化公知的特征以使给出的框架和方法的示范性实施方式的描述清楚，并且从而更好地解释给出的框架和方法。此外，为便于理解，将某些方法步骤描绘为分开地步骤；然而，这些分开地描绘步骤不应该被看作是依赖其性能的必须的次序。

此处描述的框架可以实现为方法、计算机控制的装置、计算机处理、计算系统、或诸如计算机可用介质的制品。从以下描述，这些和各种其他特征将是清楚的。

图1示出的框图示出了可以用来实现此处描述的框架的示范性系统100。系统100可以包括可通信地耦接到输入设备102(例如，键盘、触摸板、麦克风、照相机等）和输出设备104(例如，显示设备、监视器、打印机、扬声器等）的计算机系统106。计算机系统106还可以包括用于使用通信链路130(例如，电话线、无线网络链路、有线网络链路或电缆网)与网络132交换数据的通信卡或设备116(例如，调制解调器和/或网络适配器)。网络132可以是局域网(LAN)或广域网(WAN)。计算机系统106可以经由网络132可通信地耦接到一个或多个其他计算机系统154。例如，计算机系统106可以充当服务器并且使用到一个或多个客户端计算机150的逻辑联接而在网络环境中操作。

计算机系统106包括中央处理单元(CPU)114、输入/输出(I/O)单元110和存储器模块112。诸如高速缓存、电源、时钟电路和通信总线之类的其他支持电路也可以包括在计算机系统106中。此外，可以通过专用集成电路补充上述中的任何一个，或者可以通过专用集成电路合并上述中的任何一个。计算机系统106的示例包括能够以定义的方式响应于并运行指令的手持设备、移动设备、个人数字助理(PDA)、工作站、服务器、便携式膝上型计算机、其它便携式设备、通用微型计算机、大型计算机、存储系统、专用数字设备、设备、组件、其他设备，或者这些的一些组合。

存储器模块112可以是任何形式的非临时性计算机可读介质，包括但不限于，动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、闪速存储器件、磁盘、内部硬盘、活动磁盘、磁光磁盘、光盘只读存储器(CD-ROM)、任何其他易失性的或非易失性存储器，或者其组合。

存储器模块112用来存储机器可执行指令、数据和各种程序，诸如用于实现此处描述的技术的操作系统120、数据库122和数据库管理系统(DBMS)123，上述的全部都可以由CPU114处理。因而，当运行机器可执行指令时计算机系统106是成为特定目的计算机系统的通用计算机系统。可替换地，此处描述的各种技术可以实现为通过操作系统120运行的软件产品的部分。可以以高级程序或面向对象的程序设计语言(例如，C、C++、Java等)实现每个计算机程序，或者如果期望则以汇编或机器语言实现每个计算机程序。该语言可以是编译或解释语言。机器可执行指令不意指局限于任一特定程序设计语言及其实现。将理解的是，各种编程语言及其编码可以用来实现此处包含的公开的教导。

在一个实施方式中，数据库122包括至少一个数据库表格。数据库表格可以存储在随机存取存储器或大容量存储器单元中。此外，一个或多个索引表可以提供以提高访问数据库表格的速度。数据库表格可以包括用于数目为N的数据字段的N+1列，其中一个列用于存储密钥。每行构成一个记录，并且该行中的密钥可以用来访问来自数据库表格的各个记录。索引表可以将至少一个数据字段的数据值关联到包含用于该数据字段的给定数据值的记录的密钥。

数据库表格可以是面向列或面向行的。通过将一个列的数据值、然后下一列的数据值等等串行化来存储面向列的数据库表格。相反地，面向行的数据库表格存储为数据行的分段（section）。数据库表格的组织通常影响为了优化性能而生成或选择的查询计划的类型。

DBMS 123包括用于定义、管理和处理数据库122的程序的集合。客户端计算机150处的用户可以与用户界面152交互以经由DBMS 123与数据库122通信。用户和DBMS 123可以通过用户界面152交换交易消息。例如，用户可以向DBMS 123发送查询，而DBMS 123可以使用数据库122处理该查询。当事务完成时，例如，DBMS 123以结果命中列表的形式向用户发送结果。

将理解地是，计算机系统106的不同的组件可以位于不同的机器上。例如，数据库122和DBMS 123可以存在于不同的物理机器中。还将理解地是，客户端计算机150的不同的组件也可以位于计算机系统106中。

图2是示出了通过示范性DBMS 123的查询流200的框图。可以通过计算机程序代码配置图1的计算机系统106以实现由流200表示的处理。

在一个实施方式中，DBMS 123包括查询分析器202、查询优化器204和查询专家206。查询分析器202从用户界面152接收至少一个第一查询。第一查询可以包括用于访问、修改、追加或操纵存储在数据库122中的数据的命令和/或子句的集合，并且第一查询可以符合标准语法或查询语言，诸如结构化查询语言(SQL)、SQLScript或任何其他语言。例如，它们可以指定数据库122中的特定位置(例如，数据库、表格、列或行)、对将要包括在查询结果中的特定数据记录必须适用的搜索标准、聚合方法、子查询、联接操作等等。

查询分析器202解析文本并执行第一查询的建设性（constructive）分析。查询分析器202可以除去冗余数据或执行错误检查，诸如验证第一查询的语法、确认表格当中的关系等。此外，查询分析器202可以将第一查询转换成为结构化对象，诸如二叉树数据结构或任何其他合适的数据结构。例如，结构化对象可以包含具有有意义语法的查询的分段，诸如填充的列名称，使用的计算方法，分类字段，联接条件等。

查询优化器204从查询分析器202接收结构化对象并且自动地重写第一查询以生成第二查询。类似于第一查询，第二查询也可以符合定义的查询语言(例如，SQL、SQLScript)。第二查询产生对于下层数据库122最有效的查询计划。例如，可以基于指定行为的先验知识和下层数据库122的特性来确定产生的查询计划。在一个实施方式中，通过对于优化第一查询识别属于哪个场景，并且执行相应的优化操作以重写第一查询来生成第二查询，如稍后将更详细描述的。可以基于下层数据库的特性预定义相应的操作。

查询优化器204使第二查询传递到查询专家(query advisor)206。查询专家206可以生成一个或多个建议(或注释)，该建议(或注释)推荐通过用户的进一步的动作以利用第二查询产生更好的性能。这种建议在系统级、整体级或数据库管理级，而不是语句级提供推荐。例如，该建议可以向用户提供关于如何修改环境或模式以改善性能的建议，诸如除去用于特定表格中的指定列的压缩等。

通过查询专家206生成的第二查询和/或任一建议可以通过用户界面152呈现给用户。然后，用户可以依照期望完成任一修改，并且相对于数据库122运行修改的第二查询以访问和操纵存储在其中的数据。不同于提供“EXPLAIN”功能以便程序员可以预览和监视用于性能调节的查询计划的传统方法，本公开的框架自动地生成适合下层数据库的指定特征或特性的优化的查询语句。通过提供基于下层数据库的指定特性的先验知识来预定义的优化功能的集合以实现此功能。

不熟悉下层数据库的程序员现在能够通过给出的框架容易地和有效地优化查询。由于不需要用户的专门知识或先前经验用于性能调节，所以提供该附加的优点使得新数据库产品被市场更广泛地接受。当数据量变化时，全部用户需要做的是输入第一查询并且利用通过本框架输出的修改的第二查询，而不必须重新人工地执行冗长的和困难的性能调节处理。

图3示出用于优化数据库查询的示范性方法300。可以通过计算机系统106实现示范性方法300，如参照图1先前描述的。

在302，查询优化器204接收第一查询。例如，第一查询可以以结构化对象、或由查询分析器202生成的任一其他数据结构的形式。第一查询可以包括语言元素的集合，诸如子句、表达式、谓语、询问等。在SQL语言中，例如，JOIN子句组合来自数据库中的两个或多个表格的记录。

在304，查询优化器204分析第一查询并且基于第一查询的语法自动地识别用于优化的至少一个场景。场景是指可以通过重写而对于下层数据库被优化的查询的类型。每个场景可以包括子场景。在一个实施方式中，基于使用的查询语言的特定语法预定义每个场景。每个场景和/或子场景可以映射到用于重写第一查询的相应的功能模块或预定义的操作。

图4示出用于优化的预定义的场景(402a-d)和子场景(406a-d)。应该理解地是，本公开的框架不局限于此示出的场景，或者SQL查询语言。例如，可以提供大于4个预定义的场景，或者可以基于使用的指定查询语言来预定义其他类型的场景。

如所示，预定义的场景(402a-d)可以包括Join（联接）、Dynamic SQL（动态SQL）、Sub-query（子查询）和Other（其它）场景。可以通过检测第一查询中的指定语法来识别预定义的场景。例如，通过检测第一查询中的JOIN子句来识别“Join”场景。可以通过检测子句“exec()”来识别“DynamicSQL”场景。附加地，可以通过检测嵌套在至少一个SELECT（选择）、INSERT（插入）、UPDATE（更新）或DELETE（删除）语句、或另一子查询内的SELECT子句来识别“Sub-query（子查询）”场景。“Other”场景组合不属于其它3个主场景的各种杂项的子场景。

反过来参考图3，在306，查询优化器204确定场景是否命中。如果相应的功能模块可以用来重写和优化第一查询，则该场景命中。如果没有找到功能模块，则处理300在312继续以检查是否存在另一将要处理的场景。如果找到相应的功能模块，则处理300在308继续以通过重写第一查询来生成第二查询。

每个功能模块实现一个或多个预定义的操作以自动地生成第二查询。第二查询功能上等效于第一查询(即，返回相同的结果)，但是以更有效的方式(例如，更快速和需要更少资源)来访问或操纵下层数据库中的信息。在一个实施方式中，基于数据库的指定类型(例如，面向列或面向行）的特定特性、或者数据库或数据库管理系统的指定实现(例如，SAP HANA、Sybase IQ、微软SQL等)的先验知识来定制功能模块。可替换地，功能模块可以被设计为一般可应用于大部分或各种数据库或数据库管理系统(例如，面向行或面向列两者）。用户界面152可以向用户提供选项以选择是否使用数据库专用功能模块或一般通用的功能模块。

本框架的一个实施方式提供用于优化被分类为“Join”场景的第一查询的第一功能模块。如图4所示，“Join”场景可以进一步被划分成示范性子场景：Type（类型）、Sequence（序列）、Condition（条件）。将理解地是，还可以提供其他类型的子场景。

第一功能模块可以通过重写“Type”子场景查询以改变“Join”类型来优化“Type”子场景查询。一般存在四个类型的“Join”查询：Inner（内）、Outer（外）、Leftand Right（左和右）。“Inner Join（内联接）”可以转换成等效的“Outer Join（外联接）”，反之亦然。

例如，典型的“Inner Join”查询如下：

SELECT VBELN,POSNR FROM VBAP_ST1

     INNER JOIN VBAP T2 ON T1.MAND=T2.MANDT AND

     T1.VBELN=T2.VBELN AND T1.POSNR=T2.POSNR;

这种“Inner Join”查询语句可以重写为等效的“Left Outer Join（左外联接）”语句以提高性能，如下：

SELECT VBELN,POSNR FROM VBAP_ST1

     LEFT OUTER JOIN VBAP T2 ON T1.MAND=T2.MANDT

     AND T1.VBELN=T2.VBELN AND T1.POSNR=T2.POSNR;

在其他情况中，“Left Outer Join”或“Right Outer Join（右外联接）”还可以重写为等效的“Inner Join”以便改善数据库访问的速度。取决于下层数据库的指定特性，其他类型的“Join”查询语句也可以被重写以提高数据库性能。

可以通过重新排列查询中的“Join”语句的次序来优化“Sequence”子场景查询。如果“Join”语句被不同地排序，则一些数据库生成不同的查询计划。因而，期望以特定顺序重新排列“Join”语句的次序以便优化下层数据库的性能。

例如，利用多个“Inner Join”语句的典型的查询如下：

可以通过重新排序“Inner Join”语句来优化这种查询以使得处于相同的业务级(例如，次序级（orderlevel）、项目级、调度行级）的表格位于相邻位置。例如，可以将表格B1、A2、B2(其中A和B每个表示一个业务级别)排序为A2、B1、B2，如下：

作为另一示例，利用多个类型的“Join”语句(例如，“Left Outer Join,”“Inner Join”)的典型的查询如下：

可以通过将“Inner Join”排序在“Left Outer Join”语句之前来优化这种查询，如下：

可以通过改变查询的“Join”语句中的一个或多个条件来优化“Condition”子场景查询。例如，通常不期望“Circular Joins（循环联接）”用于许多数据库，因为它们使得产生的查询计划非常低效。“Circular Join”查询将三个或多个表格链接在一起成为回路（circuit）。例如，典型的“Circular Join”查询如下：

可以通过改变条件(例如，将“VBAK.MANDT=VBUP.MANDT”改变为“VBAP.MANDT=VBUP.MANDT”)而以“non-circular（非循环）”形式重写这种″Circular Join″查询以使得避免将表格联接成为回路，如下：

本框架的一个实施方式提供用于优化被分类为“Dynamic SQL”场景的第二查询的第二功能模块。“Dynamic SQL”场景可以进一步划分成示范性子场景：Replacement（替换）、Separating（分开）。将理解的是，还可以提供其他类型的子场景。

第二功能模块可以通过将动态SQL查询转换成为等效的非动态SQL形式来优化“Replacement”子场景查询。此特征识别的事实是在某些数据库中动态SQL查询经常比非动态SQL查询运行的更慢。

例如，典型的动态SQL查询可以如下：

SQL1:=‘SELECT FIELD1,FIELD2,…FIELDN FROM T1’

||:TMP_STR;

因为条件不是很复杂，所以可以通过使用“if-else”语句以非动态SQL形式重写这种查询，如下：

“Separating”子场景查询是较长和/或复杂的SQL查询，在某些数据库中可以通过将“Separating”子场景分开成为两个或多个部分来优化它以避免性能问题。

例如，长动态SQL查询可以如下：

SQL1:=‘SELECT FIELD1,FIELD2…FIELDN FROM(…)AS T1’||

‘INNER JOIN(…)AS T2 ON(T1.K1=T2.K1 AND T1.K2=T2.K2)’;

为了优化这种查询，动态SQL语句的第一部分的结果可以首先存储在全局临时列表格（例如，G_T1)或任一其他临时数据结构中。临时列表格然后可以被选择并在第二部分的子查询中被联接以获得最终答案，如下：

INSERT INTO G_T1 FIELD1,FIELD2…FIELDN FROM(…)AS T1;

SQL1:=‘SELECT FIELD1,FIELD2…FIELDN FROM G_T1‘||‘INNER

JOIN(….)AS T2ON(T1.K1=T2.K1 AND T1.K2=T2.K2)’;

作为另一示例，具有“Orderby”子句的复杂动态SQL query可以如下：

SQL1:=‘SELECT FIELD1…FIELDN FROM(..a very long sql statement)’

||:ORDERBY_STR

“Order by”子句指定SQL SELECT（SQL选择）语句返回的结果集合具有按照一个或多个列的值分类的行。因为在某些数据库中“Order by”子句会引起性能问题，所以可以通过将这种查询分开成为两个或多个分开的部分、并且在该查询的最后部分包括分类或“Order by”子句来优化这种查询。例如，这可以通过首先将数据集保存在临时表格(例如，T1)中，然后利用“Order by”子句运行来自保存的临时表格的额外“Select”查询语句来实现，如下：

INSERT INTO T1SELECT FIELD1…FIELDN FROM(..the very long sqlstatement);

SQL1:=SELECT FIELD1…FIELDN FROM T1||:ORDERBY_STR;

在另一示例中，具有数据依赖性的动态SQL查询在某些数据库中会引起性能问题。可以通过将该依赖性分开成为两个或多个不同的存储过程来优化这种查询。例如，具有数据依赖性的动态SQL查询可以包括将动态“Select”查询语句的结果供给另一查询语句的存储过程，如下：

为了优化该查询，动态“Select”查询语句可以重写为独立的存储过程(例如，SP2)，然后被调用以使用动态“Select”结果，如下：

本框架的一个实施方式提供用于优化被分类为“Sub-query”场景的第三查询的第三功能模块。“Sub-query”场景可以进一步划分成示范性子场景：Where-clause(Where子句)、Distinct data（不重复数据）。将理解的是，还可以提供其他类型的子场景。

“Where-clause”子场景查询包括子查询语句内部或外部的“Where”子句。可以通过重写这种查询以使得“Where”子句移动到子查询语句外或移动到子查询语句中来优化这种查询。

更具体地，如果子查询语句较长和复杂，则可以通过将“Where”子句移动到子查询语句外并且移动到主查询体中来减少查询运行时间。此外，还可以将具有高复杂度但是低滤过率(即，不显著地减少通过查询返回的结果)的任一条件移出子查询语句。

例如，典型的“Where-clause”子场景查询可以如下：

可以通过将“Where”子句条件移出子查询语句并且移到主查询体中来缩短子查询语句，如下：

用于子查询语句的表格较大并且“Where”子句条件显著地过滤数据行的情况下，可以通过将来自主查询体的“Where”子句条件移动到子查询语句中来优化查询。例如，典型的“Where-clause”子场景查询可以如下：

可以通过将“Where”子句条件置于主查询中而不是置于子查询语句中来优化这种查询，如下：

“Distinct data”子场景查询是可以通过添加“DISTINCT”关键字被优化的一个。例如，示范性“Where-clause”子场景查询可以利用通过子查询返回的“IN”运算符的值而在“Where”子句中包括“IN”运算符。填充的子查询数据可能包含重复行。为了避免通过子查询返回的重复值，可以重写以在“Select”语句中包括“DISTINCT”关键字。

例如，典型的“Where-clause”子场景查询可以如下：

SELECT FIELD1,FIELD2 FROM T1 WHERE T1.FIELD3 IN(SELECTFIELD3 FROM T2)

可以通过在子查询的“Select”语句中使用“DISTINCT”关键字来重写这种查询，如下：

SELECT FIELD1,FIELD2 FROM T1 WHERE T1.FIELD3 IN(SELECTDISTINCT FIELD3 FROM T2)

本框架的一个实施方式提供用于优化被分类为“Others”场景的查询的第四功能模块。“Others”场景可以进一步划分成示范性子场景：Populate（填充）、Parallel（并行）、Sorting（分类）、Useless(无用)。将理解的是，还可以提供其他类型的子场景。

第四功能模块可以通过使用“SELECT[the fields needed（需要的字段）]”而不是“SELECT*”来优化“Populate”子场景查询。这是为避免填充不必要字段或列。例如，典型的“Populate”子场景查询可以如下：

SELECT*FROM T1;

可以通过如下重写这种查询来对其进行优化：

SELECT FIELD1,FIELD2 FROM T1;

可以通过重写“Parallel”子场景查询以采用并行计算来优化它。例如，一些数据库(例如，SAP HANA)提供触发并行计算的功能“CE_UNION_ALL”。为了改善性能，包括“UNION ALL”功能的查询可以被重写为利用“CE_UNION_ALL”功能替换“UNIONALL”功能。

例如，典型的“Parallel”子场景查询可以如下：

SELECT FIELD1,FIELD2…FIELDN FROM(…)AS T1

UNION ALL SELECT FIELD1,FIELD2…FIELDN FROM(…)AS T2

可以通过将全部“UNION”语句分开成为独立成份、并且使用“CE_UNION_ALL”功能以合并成分来优化这种查询，如下：

T1=SELECT FIELD1,FIELD2…FIELDN FROM(…)AS T1;

T2=SELECT FIELD1,FIELD2…FIELDN FROM(…)AS T2;

T3=CE_UNION_ALL(:T1,:T2);

“Sorting”子场景查询包括用于对从数据库检索到的数据集合进行排序的“Orderby”子句。“Orderby”的性能在某些数据库中不是非常有效，特别是对于一个长查询中具有复杂查询逻辑或多个“Order by”子句。如果可能，可以通过重写这种查询以最小化或避免“Order by”的使用来对其进行优化。

例如，典型的“Sorting”子场景查询可以如下：

因为在这种情况下“Order by”的使用是不可避免的，所以可以通过将“Orderby”子句置于子查询语句的外部来优化查询，如下：

可以通过重新排列任一“useless”标准来优化“Useless”子场景查询。“useless”标准是不实质上减少查询结果的填充的数据尺寸的一个。例如，典型的“Useless”子场景查询可以如下：

为了优化这种查询，可以从子查询语句移去“useless”标准并且移入到查询的最外侧主体里，如下：

反过来参考图3，在310，查询专家206基于第一查询生成一个或多个建议。不同于查询优化器204，查询专家206不重写查询。作为替代，它生成一个或多个建议，该建议推荐可以由用户完成以便改善数据库性能的改变。

例如，由存储过程加密（wrapped）的SQL语句会比纯(或非过程的)SQL语句运行更慢，因为它产生效率较差的查询计划和/或触发更低的存储器分配。在这种情况中，查询专家206可以生成建议以提议使用程序设计语言（诸如高级企业应用程序(ABAP)或JAVA）直接实现SQL语句，而不是将逻辑写为SQL存储过程。然后，开放式数据库连接性(ODBC)或Java数据库连接性(JDBC)连接可以用于调用该过程。

在另一示例中，在大量的数据插入数据结构的情况中，查询专家206可以生成建议。例如，它可以推荐将数据插入到全局临时列表格中而不是插入局部列表格中。这已经被发现快很多，并且避免会话管理的需要和数据冲突，特别是在多处理情况。应当注意，还可以使用全局临时行表格或其他数据结构。

可以如下创建示范性全局临时列表格：

在另一示例中，查询专家206可以生成建议，该建议推荐去除字段压缩，特别是当建立很复杂的查询语句时。字段压缩可以减少存储器使用，但是它减弱性能，特别是在具有许多子查询语句的长复杂查询中。如果指定字段的压缩频繁地用在查询中作为过滤器或索引，则可以人工地除去指定字段的压缩。例如，可以使用以下代码切断压缩：

ALTER TABLE <table name> WITH

PARAMETERS(′AUTO_OPTIMIZE_COMPRESSION′=′OFF′)

在另一示例中，查询专家206可以生成建议，该建议推荐使用由下层数据库提供的特定语句以优化插入或删除。例如，SAP HANA提供将列存储表格delta部分合并到它的主要部分的“MERGE DELTA”语句。这对频繁地改变特别有用。例如，典型的查询可以如下：

DELETE FROM EX_OUT_XTAB;

INSERT INTO EX_OUT_XTAB

SELECT......

查询专家206可以生成建议，该建议提议通过在插入的新回合之前合并delta索引来修改查询，如下：

一旦基于第一查询生成第二查询和/或建议，它们就可以经由用户界面152(例如，实现在显示设备上的图形用户界面）显示给用户用于评价。图5示出示范性用户界面152。用户可以与用户界面152交互以与计算机系统106通信从而执行性能调节。在一个实施方式中，用户指定配置信息(例如，服务器、客户端、用户和概要信息)并且通过单击按钮504连接到计算机系统106。

当配置成功时，用户可以在文本框506中输入原始的查询语句，并且单击按钮508以启动优化。在计算机系统106完成性能调节之后，在文本框510中显示优化的查询语句。可以在文本框512中显示额外的建议。然后，用户可以基于建议接受、拒绝或修改优化的查询语句，并且运行查询以检索或操作来自下层数据库122的数据。

虽然已经具体于结构特点和/或方法学的步骤以语言描述了一个或多个上面描述的实现，但是将理解，可以实行其他实现而没有描述的指定特征或步骤。相反地，公开特定特征和步骤作为一个或多个的优选形式。

Claims (21)

1.一种数据库查询优化的方法，包括：

(a)接收第一查询；

(b)由计算机通过在第一查询中检测指定语法来自动地识别用于优化的至少一个场景；以及

(c)由计算机通过使用与识别的场景对应的预定义的操作来重写第一查询以自动地生成第二查询。

2.如权利要求1所述的方法，其中所述第一查询和第二查询包括结构化查询语言(SQL)查询。

3.如权利要求1所述的方法，其中所述第一查询包括通过查询分析器生成的结构化对象。

4.如权利要求1所述的方法，其中所述场景包括“Join（联接）”场景。

5.如权利要求4所述的方法，其中所述预定义的操作包括改变第一查询的“Join”类型。

6.如权利要求5所述的方法，其中改变所述“Join”类型包括将第一查询从“Inner Join（内联接）”形式转换为等效的“Outer Join（外联接）”形式。

7.如权利要求5所述的方法，其中改变所述“Join”类型包括将第一查询从“Outer Join（外联接）”形式转换为等效的“Inner Join（内联接）”形式。

8.如权利要求4所述的方法，其中所述预定义的操作包括重新排列第一查询中的“Join”语句。

9.如权利要求8所述的方法，其中重新排列所述“Join”语句包括重新排列“Inner Join”语句以使得处于相同的业务级别的表格位于相邻位置。

10.如权利要求8所述的方法，其中重新排列所述“Join”语句包括将“Inner Join”语句排序在“Left Outer Join（左外联接）”语句之前。

11.如权利要求4所述的方法，其中所述预定义的操作包括改变“Join”语句中的一个或多个条件。

12.如权利要求4所述的方法，其中所述预定义的操作包括将第一查询从循环形式转换到等效的非循环形式。

13.如权利要求1所述的方法，其中所述场景包括“Dynamic SQL（动态SQL）”场景。

14.如权利要求13所述的方法，其中所述预定义的操作包括将第一查询从动态SQL形式转换到非动态SQL形式。

15.如权利要求13所述的方法，其中所述预定义的操作包括使用临时数据结构将第一查询分开成为两个或多个部分。

16.如权利要求13所述的方法，其中所述预定义的操作包括将第一查询中的数据依赖性分开成为两个或多个不同的存储过程。

17.如权利要求1所述的方法，其中所述场景包括“Sub-query（子查询）”场景。

18.如权利要求17所述的方法，其中所述预定义的操作包括将“Where”子句从第一查询的子查询语句中移出或移入到第一查询的子查询语句中。

19.如权利要求1所述的方法，还包括基于第一查询生成一个或多个建议。

20.一种具有存储在其上的程序代码的非临时性计算机可读介质，所述程序代码由计算机执行以进行下述步骤：

接收第一查询；

通过在第一查询中检测指定语法来自动地识别用于优化的至少一个场景；以及

通过使用与该识别情形对应的预定义的操作来重写第一查询以自动地生成第二查询。

21.一种系统，包括：

非临时性存储设备，用于存储计算机可读程序代码；以及

与存储设备通信的处理器，该处理器利用计算机可读程序代码可操作以进行如下步骤：

接收第一查询；

通过在第一查询中检测指定语法来自动地识别用于优化的至少一个场景；以及

通过使用与该识别情形对应的预定义的操作来重写第一查询以自动地生成第二查询。

Images