SQL优化.docx

SQL优化.docx

《SQL优化.docx》由会员分享，可在线阅读，更多相关《SQL优化.docx（67页珍藏版）》请在冰点文库上搜索。

SQL优化

通过分析SQL语句的执行计划优化SQL（总结）

做DBA快7年了，中间感悟很多。

在DBA的日常工作中，调整个别性能较差的SQL语句时一项富有挑战性的工作。

其中的关键在于如何得到SQL语句的执行计划和如何从SQL语句的执行计划中发现问题。

总是想将日常经验的点点滴滴总结一下，但是直到最近才下定决心，总共花了3个周末时间，才将其整理成册，便于自己日常工作。

不好意思独享，所以将其贴出来。

第一章、第2章并不是很重要，是自己的一些想法，关于如何做一个稳定、高效的应用系统的一些想法。

第三章以后都是比较重要的。

附录的内容也是比较重要的。

我常用该部分的内容。

                                前言

    本文档主要介绍与SQL调整有关的内容，内容涉及多个方面：

SQL语句执行的过程、ORACLE优化器，表之间的关联，如何得到SQL执行计划，如何分析执行计划等内容，从而由浅到深的方式了解SQL优化的过程，使大家逐步步入SQL调整之门，然后你将发现……。

    该文档的不当之处，敬请指出，以便进一步改正。

请将其发往我的信箱：

xu_yu_jin2000@。

    如果引用本文的内容，请著名出处！

第1章性能调整综述

  Oracle数据库是高度可调的数据库产品。

本章描述调整的过程和那些人员应与Oracle服务器的调整有关，以及与调整相关联的操作系统硬件和软件。

本章包括以下方面:

l    谁来调整系统?

l    什么时候调整?

l    建立有效调整的目标

l    在设计和开发时的调整

l    调整产品系统

l    监控产品系统

谁来调整系统:

  为了有效地调整系统，若干类人员必须交换信息并牵涉到系统调整中，例如:

l    应用设计人员必须传达应用系统的设计，使得每个人都清楚应用中的数据流动.

l    应用开发人员必须传达他们选择的实现策略，使得语句调整的过程中能快速、容易地识别有问题的应用模块和可疑的SQL语句.

l    数据库管理人员必须仔细地监控系统活动并提供它们的资料，使得异常的系统性能可被快速得识别和纠正.

l    硬件/软件管理人员必须传达系统的硬件、软件配置并提供它们的资料，使得相关人员能有效地设计和管理系统。

  简而言之，与系统涉及的每个人都在调整过程中起某些作用，当上面提及的那些人员传达了系统的特性并提供了它们的资料，调整就能相对的容易和更快一些。

    不幸的是，事实上的结果是：

数据库管理员对调整负有全部或主要的责任。

但是，数据库管理员很少有合适的系统方面的资料，而且，在很多情况下，数据库管理员往往是在实施阶段才介入数据库，这就给调整工作带来许多负面的影响，因为在设计阶段的缺陷是不能通过DBA的调整而得以解决，而设计阶段的缺陷往往对数据库性能造成极大的影响。

    其实，在真正成熟的开发环境下，开发人员作为纯代码编写人员时，对性能的影响最小，此时大部分的工作应由应用设计人员完成，而且数据库管理员往往在前期的需求管理阶段就介入，为设计人员提供必要的技术支持。

调整并不是数据库管理员的专利，相反大部分应该是设计人员和开发人员的工作，这就需要设计人员和开发人员具体必要的数据库知识，这样才能组成一个高效的团队，然而事实上往往并非如此。

什么时候作调整？

    多数人认为当用户感觉性能差时才进行调整，这对调整过程中使用某些最有效的调整策略来说往往是太迟了。

此时，如果你不愿意重新设计应用的话，你只能通过重新分配内存（调整SGA）和调整I/O的办法或多或少地提高性能。

Oracle提供了许多特性，这些特性只有应用到正确地设计的系统中时才能够很大地提高性能。

    应用设计人员需要在设计阶段设置应用的性能期望值。

然后在设计和开发期间，应用设计人员应考虑哪些Oracle特性可以对系统有好处，并使用这些特性。

通过良好的系统设计，你就可以在应用的生命周期中消除性能调整的代价和挫折。

图1-1图1-2说明在应用的生命周期中调整的相对代价和收益，正如你见到的，最有效的调整时间是在设计阶段。

在设计期间的调整能以最低的代价给你最大的收益。

图1-1　在应用生命周期中调整的代价　

　　　　　　图1-2  在应用生命周期中调整的收益

  当然，即使在设计很好的系统中，也可能有性能降低。

但这些性能降低应该是可控的和可以预见的。

调整目标

    不管你正在设计或维护系统，你应该建立专门的性能目标，它使你知道何时要作调整。

如果你试图胡乱地改动初始化参数或SQl语句，你可能会浪费调整系统的时间，而且无什么大的收益。

调整你的系统的最有效方法如下：

l    当设计系统时考虑性能

l    调整操作系统的硬件和软件

l    识别性能瓶颈

l    确定问题的原因

l    采取纠正的动作

当你设计系统时，制定专门的目标；例如，响应时间小于３秒。

当应用不能满足此目标时，识别造成变慢的瓶颈（例如，I/O竞争），确定原因，采取纠正动作。

在开发期间，你应测试应用研究，确定在采取应用之前是否满足设计的性能目标。

    当你正在维护生产库系统时，有多种快速有效的方法来识别性能瓶颈。

不管怎样，调整通常是一系列开销。

一旦你已确定了瓶颈，你可能要牺牲一些其它方面的指标来达到所要的结果。

例如，如果I/O有问题，你可能需要更多内存或磁盘。

如果不可能买，你可能要限制系统的并发性，来获取所需的性能。

然而，如果你已经明确地定义了性能的目标，那用什么来交换高性能的决策就变的很容易的，因为你已经确定了哪些方面是最重要的，如过我的目标为高性能，可能牺牲一些空间资源。

    随着应用的越来越庞大，硬件性能的提高，全面的调整应用逐渐变成代价高昂的行为，在这样情况下，要取得最大的投入/效率之比，较好的办法是调整应用的关键部分，使其达到比较高的性能，这样从总体上来说，整个系统的性能也是比较高的。

这也就是有名的20/80原则，调整应用的20%（关键部分），能解决80%的问题。

在设计和开发系统时作调整

    良好设计的系统可以防止在应用生命周期中产生性能问题。

系统设计人员和应用开发人员必须了解Oracle的查询处理机制以便写出高效的SQL语句。

“第2章有效的应用设计”讨论了你的系统中各种可用的配置，以及每种配置更适合哪种类型的应用。

“第5章优化器”讨论了Oracle的查询优化器，以及如何写语句以获取最快的结果。

当设计你的系统时，使用下列优化性能的准则：

l    消除客户机／服务器应用中不必要的网络传输。

--使用存储过程。

l    使用适合你系统的相应Oracle服务器选件（例如，并行查询或分布式数据库）。

l    除非你的应用有特殊的需要，否则使用缺省的Oracle锁。

l    利用数据库记住应用模块，以便你能以每个模块为基础来追踪性能。

l    选择你的数据块的最佳大小。

  --原则上来说大一些的性能较好。

l    分布你的数据，使得一个节点使用的数据本地存贮在该节点中。

调整产品系统

    本节描述对应用系统快速、容易地找出性能瓶颈，并决定纠正动作的方法。

这种方法依赖于对Oracle服务器体系结构和特性的了解程度。

在试图调整你的系统前，你应熟悉Oracle调整的内容。

为调整你已有的系统，遵从下列步骤：

l    调整操作系统的硬件和软件

l    通过查询V$SESSION_WAIT视图，识别性能的瓶颈，这个动态性能视图列出了造成会话（session）等待的事件。

l    通过分析V$SESSION_WAIT中的数据，决定瓶颈的原因。

l    纠正存在的问题。

监控应用系统

这主要是通过监控oracle的动态视图来完成。

各种有用的动态视图：

如v$session_wait,v$session_event等。

                          第2章有效的应用设计

    我们通常将最常用的应用分为2种类型：

联机事务处理类型（OLTP），决策支持系统（DSS）。

联机事务处理（OLTP）

    该类型的应用是高吞吐量，插入、更新、删除操作比较多的系统，这些系统以不断增长的大容量数据为特征，它们提供给成百用户同时存取，典型的OLTP系统是订票系统，银行的业务系统，订单系统。

OTLP的主要目标是可用性、速度、并发性和可恢复性。

    当设计这类系统时，必须确保大量的并发用户不能干扰系统的性能。

还需要避免使用过量的索引与cluster表，因为这些结构会使插入和更新操作变慢。

决策支持（DSS）

    该类型的应用将大量信息进行提取形成报告，协助决策者作出正确的判断。

典型的情况是：

决策支持系统将OLTP应用收集的大量数据进行查询。

典型的应用为客户行为分析系统（超市，保险等）。

    决策支持的关键目标是速度、精确性和可用性。

    该种类型的设计往往与OLTP设计的理念背道而驰，一般建议使用数据冗余、大量索引、clustertable、并行查询等。

    近年来，该类型的应用逐渐与OLAP、数据仓库紧密的联系在一起，形成的一个新的应用方向。

第3章  SQL语句处理的过程

          在调整之前我们需要了解一些背景知识，只有知道这些背景知识，我们才能更好的去调整sql语句。

本节介绍了SQL语句处理的基本过程，主要包括：

·    查询语句处理

·    DML语句处理（insert,update,delete）

·    DDL语句处理（create..,drop..,alter..,）

·    事务控制（commit,rollback）

SQL语句的执行过程（SQLStatementExecution）

        图3-1概要的列出了处理和运行一个sql语句的需要各个重要阶段。

在某些情况下，Oracle运行sql的过程可能与下面列出的各个阶段的顺序有所不同。

如DEFINE阶段可能在FETCH阶段之前，这主要依赖你如何书写代码。

        对许多oracle的工具来说，其中某些阶段会自动执行。

绝大多数用户不需要关心各个阶段的细节问题，然而，知道执行的各个阶段还是有必要的，这会帮助你写出更高效的SQL语句来，而且还可以让你猜测出性能差的SQL语句主要是由于哪一个阶段造成的，然后我们针对这个具体的阶段，找出解决的办法。

图3-1  SQL语句处理的各个阶段

DML语句的处理

    本节给出一个例子来说明在DML语句处理的各个阶段到底发生了什么事情。

假设你使用Pro*C程序来为指定部门的所有职员增加工资。

程序已经连到正确的用户，你可以在你的程序中嵌入如下的SQL语句：

EXECSQLUPDATEemployees

SETsalary=1.10*salary

        WHEREdepartment_id=:

var_department_id;

var_department_id是程序变量，里面包含部门号，我们要修改该部门的职员的工资。

当这个SQL语句执行时，使用该变量的值。

每种类型的语句都需要如下阶段：

·    第1步:

CreateaCursor    创建游标

·    第2步:

ParsetheStatement  分析语句

·    第5步:

BindAnyVariables  绑定变量

·    第7步:

RuntheStatement  运行语句

·    第9步:

ClosetheCursor    关闭游标

如果使用了并行功能，还会包含下面这个阶段：

·    第6步:

ParallelizetheStatement  并行执行语句

如果是查询语句，则需要以下几个额外的步骤，如图3所示：

·    第3步:

DescribeResultsofaQuery  描述查询的结果集

·    第4步:

DefineOutputofaQuery    定义查询的输出数据

·    第8步:

FetchRowsofaQuery      取查询出来的行

下面具体说一下每一步中都发生了什么事情：

.

第1步:

创建游标（CreateaCursor）

      由程序接口调用创建一个游标（cursor）。

任何SQL语句都会创建它，特别在运行DML语句时，都是自动创建游标的，不需要开发人员干预。

多数应用中，游标的创建是自动的。

然而，在预编译程序（pro*c）中游标的创建，可能是隐含的，也可能显式的创建。

在存储过程中也是这样的。

第2步:

分析语句（ParsetheStatement）

    在语法分析期间，SQL语句从用户进程传送到Oracle，SQL语句经语法分析后，SQL语句本身与分析的信息都被装入到共享SQL区。

在该阶段中，可以解决许多类型的错误。

语法分析分别执行下列操作：

l    翻译SQL语句，验证它是合法的语句，即书写正确

l    实现数据字典的查找，以验证是否符合表和列的定义

l    在所要求的对象上获取语法分析锁，使得在语句的语法分析过程中不改变这些对象的定义

l    验证为存取所涉及的模式对象所需的权限是否满足

l    决定此语句最佳的执行计划

l    将它装入共享SQL区

l    对分布的语句来说，把语句的全部或部分路由到包含所涉及数据的远程节点

    以上任何一步出现错误，都将导致语句报错，中止执行。

    只有在共享池中不存在等价SQL语句的情况下，才对SQL语句作语法分析。

在这种情况下，数据库内核重新为该语句分配新的共享SQL区，并对语句进行语法分析。

进行语法分析需要耗费较多的资源，所以要尽量避免进行语法分析，这是优化的技巧之一。

    语法分析阶段包含了不管此语句将执行多少次，而只需分析一次的处理要求。

Oracle只对每个SQL语句翻译一次，在以后再次执行该语句时，只要该语句还在共享SQL区中，就可以避免对该语句重新进行语法分析，也就是此时可以直接使用其对应的执行计划对数据进行存取。

这主要是通过绑定变量（bindvariable）实现的，也就是我们常说的共享SQL，后面会给出共享SQL的概念。

    虽然语法分析验证了SQL语句的正确性，但语法分析只能识别在SQL语句执行之前所能发现的错误（如书写错误、权限不足等）。

因此，有些错误通过语法分析是抓不到的。

例如，在数据转换中的错误或在数据中的错（如企图在主键中插入重复的值）以及死锁等均是只有在语句执行阶段期间才能遇到和报告的错误或情况。

查询语句的处理

    查询与其它类型的SQL语句不同，因为在成功执行后作为结果将返回数据。

其它语句只是简单地返回成功或失败，而查询则能返回一行或许多行数据。

查询的结果均采用表格形式，结果行被一次一行或者批量地被检索出来。

从这里我们可以得知批量的fetch数据可以降低网络开销，所以批量的fetch也是优化的技巧之一。

    有些问题只与查询处理相关，查询不仅仅指SELECT语句，同样也包括在其它SQL语句中的隐含查询。

例如，下面的每个语句都需要把查询作为它执行的一部分：

INSERTINTOtableSELECT...

UPDATEtableSETx=yWHERE...

DELETEFROMtableWHERE...

CREATEtableASSELECT...

具体来说，查询

·    要求读一致性

·    可能使用回滚段作中间处理

·    可能要求SQL语句处理描述、定义和取数据阶段

第3步:

描述查询结果（DescribeResultsofaQuery）

    描述阶段只有在查询结果的各个列是未知时才需要；例如，当查询由用户交互地输入需要输出的列名。

在这种情况要用描述阶段来决定查询结果的特征（数据类型，长度和名字）。

第4步:

定义查询的输出数据（DefineOutputofaQuery）  

    在查询的定义阶段，你指定与查询出的列值对应的接收变量的位置、大小和数据类型，这样我们通过接收变量就可以得到查询结果。

如果必要的话，Oracle会自动实现数据类型的转换。

这是将接收变量的类型与对应的列类型相比较决定的。

第5步:

绑定变量（BindAnyVariables）

    此时，Oracle知道了SQL语句的意思，但仍没有足够的信息用于执行该语句。

Oracle需要得到在语句中列出的所有变量的值。

在该例中，Oracle需要得到对department_id列进行限定的值。

得到这个值的过程就叫绑定变量（bindingvariables）

    此过程称之为将变量值捆绑进来。

程序必须指出可以找到该数值的变量名（该变量被称为捆绑变量，变量名实质上是一个内存地址，相当于指针）。

应用的最终用户可能并没有发觉他们正在指定捆绑变量，因为Oracle的程序可能只是简单地指示他们输入新的值，其实这一切都在程序中自动做了。

    因为你指定了变量名，在你再次执行之前无须重新捆绑变量。

你可以改变绑定变量的值，而Oracle在每次执行时，仅仅使用内存地址来查找此值。

    如果Oracle需要实现自动数据类型转换的话（除非它们是隐含的或缺省的），你还必须对每个值指定数据类型和长度。

关于这些信息可以参考oracle的相关文档，如OracleCallInterfaceProgrammer'sGuide

第6步:

并行执行语句（ParallelizetheStatement）

    ORACLE可以在SELECTs,INSERTs,UPDATEs,MERGEs,DELETEs语句中执行相应并行查询操作，对于某些DDL操作，如创建索引、用子查询创建表、在分区表上的操作，也可以执行并行操作。

并行化可以导致多个服务器进程（oracleserverprocesses）为同一个SQL语句工作，使该SQL语句可以快速完成，但是会耗费更多的资源，所以除非很有必要，否则不要使用并行查询。

第7步:

执行语句（RuntheStatement）

    到了现在这个时候，Oracle拥有所有需要的信息与资源，因此可以真正运行SQL语句了。

如果该语句为SELECT查询或INSERT语句，则不需要锁定任何行，因为没有数据需要被改变。

然而，如果语句为UPDATE或DELETE语句，则该语句影响的所有行都被锁定，防止该用户提交或回滚之前，别的用户对这些数据进行修改。

这保证了数据的一致性。

    对于某些语句，你可以指定执行的次数，这称为批处理（arrayprocessing）。

指定执行N次，则绑定变量与定义变量被定义为大小为N的数组的开始位置，这种方法可以减少网络开销，也是优化的技巧之一。

第8步:

取出查询的行（FetchRowsofaQuery）

    在fetch阶段，行数据被取出来，每个后续的存取操作检索结果集中的下一行数据，直到最后一行被取出来。

上面提到过，批量的fetch是优化的技巧之一。

第9步:

关闭游标（ClosetheCursor）

    SQL语句处理的最后一个阶段就是关闭游标

DDL语句的处理（DDLStatementProcessing）

    DDL语句的执行不同与DML语句和查询语句的执行，这是因为DDL语句执行成功后需要对数据字典数据进行修改。

对于DDL语句，语句的分析阶段实际上包括分析、查找数据字典信息和执行。

    事务管理语句、会话管理语句、系统管理语句只有分析与执行阶段，为了重新执行该语句，会重新分析与执行该语句。

事务控制（ControlofTransactions）

    一般来说，只有使用ORACLE编程接口的应用设计人员才关心操作的类型，并把相关的操作组织在一起，形成一个事务。

一般来说，我门必须定义事务，这样在一个逻辑单元中的所有工作可以同时被提交或回滚，保证了数据的一致性。

一个事务应该由逻辑单元中的所有必须部分组成，不应该多一个，也不应该少一个。

·    在事务开始和结束的这段时间内，所有被引用表中的数据都应该在一致的状态（或可以被回溯到一致的状态）

·    事务应该只包含可以对数据进行一致更改（oneconsistentchangetothedata）的SQL语句

    例如，在两个帐号之间的转帐（这是一个事务或逻辑工作单元），应该包含从一个帐号中借钱（由一个SQL完成），然后将借的钱存入另一个帐号（由另一个SQL完成）。

这2个操作作为一个逻辑单元，应该同时成功或同时失败。

其它不相关的操作，如向一个帐户中存钱，不应该包含在这个转帐事务中。

    在设计应用时，除了需要决定哪种类型的操作组成一个事务外，还需要决定使用BEGIN_DISCRETE_TRANSACTIO存储过程是否对提高小的、非分布式的事务的性能有作用。

第4章ORACLE的优化器

    优化器有时也被称为查询优化器，这是因为查询是影响数据库性能最主要的部分，不要以为只有SELECT语句是查询。

实际上，带有任何WHERE条件的DML（INSERT、UPDATE、DELETE）语句中都包含查询要求，在后面的文章中，当说到查询时，不一定只是指SELECT语句，也有可能指DML语句中的查询部分。

优化器是所有关系数据库引擎中的最神秘、最富挑战性的部件之一，从性能的角度看也是最重要的部分，它性能的高低直接关系到数据库性能的好坏。

    我们知道，SQL语句同其它语言（如C语言）的语句不一样，它是非过程化（non-procedural）的语句，即当你要取数据时，不需要告诉数据库通过何种途径去取数据，如到底是通过索引取数据，还是应该将表中的每行数据都取出来，然后再通过一一比较的方式取数据（即全表扫描），这是由数据库的优化器决定的，这就是非过程化的含义，也就是说，如何取数据是由优化器决定，而不是应用开发者通过编程决定。

在处理SQL的SELECT、UPDATE、INSERT或DELETE语句时，Oracle必须访问语句所涉及的数据，Oracle的优化器部分用来决定访问数据的有效路径，使得语句执行所需的I/O和处理时间最小。

    为了实现一个查询，内核必须为每个查询定制一个查询策略，或为取出符合条件的数据生成一个执行计划（executionplan）。

典型的，对于同一个查询，可能有几个执行