SQL语句大批量多表查询优化方案
我写这个没什么目的，只是分享一下给大家。
此为自己项目当中所碰见的。
当时也很纠结。但是优化过后。经过测试二亿条数据多表查询，在一分钟以内出来，虽然不是很快。但也尽量了。
首先，数据库表中索引如何创建我想大家都知道。
这是百度当中找到的解释已经很详细了。
聚集索引:
聚集索引基于聚集索引键按顺序排序和存储表或视图中的数据行。聚集索引按
B 树索引结构实现，B 树索引结构支持基于聚集索引键值对行进行快速检索。
非聚集索引:
既可以使用聚集索引来为表或视图定义非聚集索引，也可以根据堆来定义非聚集索引。非聚集索引中的每个索引行都包含非聚集键值和行定位符。此定位符指向聚集索引或堆中包含该键值的数据行。索引中的行按索引键值的顺序存储，但是不保证数据行按任何特定顺序存储，除非对表创建聚集索引。
唯一索引:
唯一索引确保索引键不包含重复的值，因此，表或视图中的每一行在某种程度上是唯一的。
聚集索引和非聚集索引都可以是唯一索引。
包含性列索引:
一种非聚集索引，它扩展后不仅包含键列，还包含非键列。
索引视图:
视图的索引将具体化（执行）视图，并将结果集永久存储在唯一的聚集索引中，而且其存储方法与带聚集索引的表的存储方法相同。创建聚集索引后，可以为视图添加非聚集索引。
全文索引:
一种特殊类型的基于标记的功能性索引，由 Microsoft SQL Server 全文引擎(MSFTESQL) 服务创建和维护。用于帮助在字符串数据中搜索复杂的词。
至于语法之类的就不讲解，大家百度一下就有很多。综合在表当中建立索引是靠
大家自己，如何安排才会觉得合理。在此不做建议。
第一部开始。
创建临时虚拟表。也就是用其实就是把一大堆重复用到的SQL语句放在with as 里面，取一个别名，后面的查询就可以用它
这样对于大批量的SQL语句起到一个优化的作用，而且清楚明了
具体实例
WITH BASE AS (
SELECT * FROM MDM_DISTRIBUTOR
)
SELECT * FROM BASE
这只是举例一下，在实际情况中，其实就是把一大堆重复用到的SQL语句放在with as 里面，取一个别名，后面的查询就可以用它这样对于大批量的SQL语句起到一个优化的作用，而且清楚明了
为什么要用WITH ，用with好处就是把把复杂的SQL语句全部都放到这里。把他当作一张表，进行查询。
第二部，创建临时表
语法
--创建临时表
SELECT * INTO #TEMP_REPORT_TABLE FROM BASE
--删除临时表，最好判断一下是否为空，在进行删除
IF object_id('tempdb..#TEMP_REPORT_TABLE') IS NOT NULL BEGIN
DROP TABLE #TEMP_REPORT_TABLE
END
最终优化的就是
WITH BASE AS (
--复杂SQL语句编写的地方
SELECT * FROM MDM_DISTRIBUTOR
)
--创建临时表
SELECT * INTO #TEMP_REPORT_TABLE FROM BASE
SELECT * FROM #TEMP_REPORT_TABLE
--删除临时表
IF object_id('tempdb..#TEMP_REPORT_TABLE') IS NOT NULL BEGIN
DROP TABLE #TEMP_REPORT_TABLE
END
当然WITH也可以做多个，而WITH里面也可以进行一些SQL语句的基础优化。比如开篇讲到创建索引，存储过程，和组织视图之类的。这样都可以。
当然用完临时表之后一定要记着删除，否则创建是不会成功的。
如果有条件的可以测试一下。
如何优化sql语句.txt心态决定状态，心胸决定格局，眼界决定境界。当你的眼泪忍不住要流出来的时候，睁大眼睛，千万别眨眼，你会看到世界由清晰到模糊的全过程。2010-01-18 honglove (高级程序员) 1、查询时不返回不需要的行、列 业务代码要根据实际情况尽量减少对表的访问行数，最小化结果集，在查询时，不要过多地使用通配符如：select * from table1语句，要用到几列就选择几列，如：select col1,col2 from table1;在可能的情况下尽量限制结果集行数如：select top 100 col1,col2,col3 from talbe2,因为某些情况下用户是不需要那么多的数据的。 2、合理使用EXISTS, NOT EXISTS字句 如下所示： SELECT SUM(T1.C1) FROM T1 WHERE ((SELECT COUNT(*) FROM T2 WHERE T2.C2=T1.C2)>0) SELECT SUM(T1.C1) FROM T1 WHERE EXISTS(SELECT * FROM T2 WHERE T2.C2=T1.C2) 两种产生相同的结果，但是后者的效率显然要高过于前者。银行后者不会产生大量锁定的表扫描或是索引扫描。 经常需要些一个T_SQLL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中乜嘢的记录，如： SELECT _a.hdr_key FROM hdr_tb1 a -----------tb1 a 表示tb1用别名a代替 WHERE NOT EXISTS (SELECT * FROM dt1_tb1 b WHERE a.hdr_key = b.hdr_key) SELECT _a.hdr_key FROM hdr_tb1 a -----------tb1 a 表示tb1用别名a代替 LEFT JION dt1_tb1 b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL SELECT hdr_key FROM hdr_tb1
第四章关系系统及其查询优化 习题 1．试给出各类关系系统的定义：最小关系系统；关系完备上的系统；全关系型的关系系统。 2．试述全关系型系统应满足的十二条准则，以及十二条基本准则的实际意义和理论意义。 3．试述查询优化在关系数据库中的重要性和可能性。 4．对学生-课程数据库有如下的查询： SELECT Cname FROM Student，Course，SC WHERE Student。Sno=SC。Sno AND SC。Cno=Course。Cno AND Student。Sdept=’IS’； 此查询要求信息系学生选修了的所有课程名称。试画出用关系代数表示的语法树，并用关系代数表达式优化算法对原始的语法树进行优化处理，画出优化后的标准优化树。 5．试述查询优化的一般准则。 6．试述查询优化的一般步骤。 参考答案 1．答：最小关系系统。 一个系统可定义为最小关系系统，当且仅当它： （1）支持关系数据库（关系数据结构），从用户观点看，关系数据库由表构成，并且只有表这一种结构 （2）支持选择、投影和（自然）连接运算，对这些运算不必要求定义任何物理存取路径。 关系上完备的系统： 这类系统支持关系数据结构和所有的关系代数操作（或者功能上与关系代数等价的操作）。 全关系型的关系系统： 这类系统支持关系模型的所有特征。即不仅是关系上完备的而且支持数据结构中域的概念，支持实体完整和参照完整性。 2．答：关系模型的奠基人E。F。Codd具体地给出了全关系型的关系系统应遵循的十二条基本准则。从实际意义上看，这十二条准则可以作为评价或购买关系型产品的标准。从理论意义上看，它是对关系数据模型具体而又深入的论述，是从理论和实际紧密结合的高度对关系型DBMSR 评述。 准则0 一个关系型的DBMS必须能完全通过它的关系能力来管理数据库。 准则1信息准则。关系型DBMS的所有信息都应在逻辑一级上用一种方法即表中的值显式地表示。 准则2保证访问准则。依靠表名、主码和列名的组合，保证能以逻辑方式访问关系数据库中的每个数据项（分量值）。 准则3空值的系统化处理。全关系型的DBMS应支持空值的概念，并用系统化的方式处理空值。 准则4基于关系模型的动态的联机数据字典。数据库的描述在逻辑级应该和普通数据采用同样的方式，使得授权用户可以使用查询一般数据所用的关系语言来查询数据库的描述信息。 准则5统一的数据语言准则。 准则6视图更新准则。所有理论上可更新的视图也应该允许由系统更新。 准则7高级的插入、修改和删除操作。 准则8数据物理独立性。无论数据库的数据在存储表示或存取方法上作任何变化，应用程序和终端活动都保持逻辑上的不变性。 准则9数据逻辑独立性。当对基本关系进行理论上信息不受损的任何改变时，应用程序和终端活动都保持逻辑上的不变性。
数据库优化查询计划的方法 数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、政府等部门最为重要的计算机应用之一。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。举例来说，如果数据的量积累到一定的程度，比如一个银行的账户数据库表信息积累到上百万甚至上千万条记录，全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟，由此可见查询优化技术的重要性。 在应用项目的实施中发现，许多程序员在利用一些前端数据库开发工具（如PowerBuilder、Delphi等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，导致所开发出来的应用系统效率低下，资源浪费严重。因此，如何设计高效合理的查询语句就显得非常重要。本文以应用实例为基础，结合数据库理论，介绍查询优化技术在现实系统中的运用。 分析问题 许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。
一个好的查询计划往往可以使程序性能提高数十倍。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化 处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如Oracle、Sybase等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优 化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此所写语句的优劣至关重要。下面重点说明改善查询计划的解决方案。 解决问题 下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。 1．合理使用索引 索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如
ＳＱＬＳｅｒｖｅｒ数据查询的优化方法聂文燕 摘要：SQLServer是一种功能强大的数据库管理系统，许多数据库应用系统都是以它作为后台数据库。本文在分析影响SQLSERVER数据查询效率的因素的基础上，提出了几种优化数据查询的方法。 关键词：SQLServer，数据，查询，优化 一、引言 SQLServer是是由微软公司开发的基于Windows操作系统的关系型数据库管理系统，它是一个全面的、集成的、端到端的数据解决方案，为企业中的用户提供了一个安全、可靠和高效的平台用于企业数据管理和商业智能应用。目前，许多中小型企业的数据库应用系统都是用SQLServer作为后台数据库管理系统设计开发的。设计一个应用系统并不难，但是要想使系统达到最优化的性能并不是一件容易的事。根据多年的实践，由于初期的数据库中表的记录数比较少，性能不会有太大问题，但数据积累到一定程度，达到数百万甚至上千万条，全面扫描一次往往需要数十分钟，甚至数小时。20％的代码用去了80％的时间，这是程序设计中的一个著名定律，在数据库应用程序中也同样如此。如果用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟。而且我们知道，目前数据库系统应用中，查询操作占了绝大多数，查询优化成为数据库性能优化最为重要的手段之一。 二、影响查询效率的因素 SQLServer处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给SQLServer的查询优化器，查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接，并生成若干执行计划，然后通过分析执行开销来评估每个执行计划，从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。所以，SQLServer中影响查询效率的因素主要有以下几种：1．没有索引或者没有用到索引。索引是数据库中重要的数据结构，使用索引的目的是避免全表扫描，减少磁盘I/O，以加快查询速度。 2．没有创建计算列导致查询不优化。 3．查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）。 4．返回了不必要的行和列。 5．查询语句不好，没有优化。其中包括：查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。 三、SQLServer数据查询优化方法 3.1建立合适的索引索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。当根据索引码的值搜索数据时，索引提供了对数据的快速访问。事实上，没有索引,数据库也能根据SELECT语句成功地检索到结果，但随着表变得越来越大，使用“适当”的索引的效果就越来越明显。索引的使用要恰到好处，其使用原则有： (1)对于基本表，不宜建立过多的索引； (2)对于那些查询频度高，实时性要求高的数据一定要建立索引，而对于其他的数据不考虑建立索引； (3)在经常进行连接，但是没有指定为外键的列上建立索引； (4)在频繁进行排序或分组（即进行groupby或orderby操作）的列上建立索引；
1.说明 数据库系统需要保存大量历史记录，系统内存在许多历史记录表，因此常常出现系统运行一段时间，表记录数达到一定数量后，系统响应明显变慢的现象。为尽可能的提高SQL 执行的效率，我们在编写SQL语句应该遵循一定的优化规则，使代码风格统一、规范。充分利用表索引，避免进行全表扫描；充分利用结构化编程方式，提高查询的复用能力，也许完全遵守以下方法速度未必达到想要的结果，但是养成一个好的编程习惯是重要的。 2.调优方法 2.1. 相同功能、性能的SQL语句 ORACLE采用共享内存SGA的机制，因此ORACLE会对每个不同写法的SQL进行分析，并且占用共享内存;如果书写格式完全相同，则ORACLE只分析一次，遇到相同书写格式的SQL，会直接从共享内存中获取结果集;这样便能减少共享池的开销以及代码的复用。处理方法：保证书写格式相同，包括大小写，空格位置，表别名等一致；将一些通用的SQL 语句作为公共函数由其它函数调用的方式使用。 2.2. 动态SQL：动态SQL采用变量动态绑定的方式，避免 重复解析。 2.3. 连接方式与表名顺序 多表查询时需要选择最有效率的表名顺序（基于规则的优化器有效），ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名；因此写在最后的那张基础表最先被处理，即选择记录数最少的表作为基础表，首先,扫描FROM子句中最右的那个表，并对记录进行排序,然后扫描FROM子句中最后第二个表,最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并。 2.4. 查询条件顺序 ORACLE采用自下而上的顺序解析WHERE子句，根据这个原理,表之间的连接必须写在其他WHERE条件之前，那些可以过滤掉最大数量记录的条件适合写在WHERE子句的末尾。 2.5. 语法和语义 2.5.1.SELECT子句中避免使用' * ' 使用'*' ,Oracle便会查询数据字典，依次解析各列名，应明确指定各列的名称，这样也便于理解。 Select * from t_user t;
SQL语句大批量多表查询优化方案 我写这个没什么目的，只是分享一下给大家。 此为自己项目当中所碰见的。 当时也很纠结。但是优化过后。经过测试二亿条数据多表查询，在一分钟以内出来，虽然不是很快。但也尽量了。 首先，数据库表中索引如何创建我想大家都知道。 这是百度当中找到的解释已经很详细了。 聚集索引: 聚集索引基于聚集索引键按顺序排序和存储表或视图中的数据行。聚集索引按 B 树索引结构实现，B 树索引结构支持基于聚集索引键值对行进行快速检索。 非聚集索引: 既可以使用聚集索引来为表或视图定义非聚集索引，也可以根据堆来定义非聚集索引。非聚集索引中的每个索引行都包含非聚集键值和行定位符。此定位符指向聚集索引或堆中包含该键值的数据行。索引中的行按索引键值的顺序存储，但是不保证数据行按任何特定顺序存储，除非对表创建聚集索引。 唯一索引: 唯一索引确保索引键不包含重复的值，因此，表或视图中的每一行在某种程度上是唯一的。 聚集索引和非聚集索引都可以是唯一索引。 包含性列索引: 一种非聚集索引，它扩展后不仅包含键列，还包含非键列。 索引视图: 视图的索引将具体化（执行）视图，并将结果集永久存储在唯一的聚集索引中，而且其存储方法与带聚集索引的表的存储方法相同。创建聚集索引后，可以为视图添加非聚集索引。 全文索引: 一种特殊类型的基于标记的功能性索引，由 Microsoft SQL Server 全文引擎(MSFTESQL) 服务创建和维护。用于帮助在字符串数据中搜索复杂的词。 至于语法之类的就不讲解，大家百度一下就有很多。综合在表当中建立索引是靠
大家自己，如何安排才会觉得合理。在此不做建议。 第一部开始。 创建临时虚拟表。也就是用其实就是把一大堆重复用到的SQL语句放在with as 里面，取一个别名，后面的查询就可以用它 这样对于大批量的SQL语句起到一个优化的作用，而且清楚明了 具体实例 WITH BASE AS ( SELECT * FROM MDM_DISTRIBUTOR ) SELECT * FROM BASE 这只是举例一下，在实际情况中，其实就是把一大堆重复用到的SQL语句放在with as 里面，取一个别名，后面的查询就可以用它这样对于大批量的SQL语句起到一个优化的作用，而且清楚明了 为什么要用WITH ，用with好处就是把把复杂的SQL语句全部都放到这里。把他当作一张表，进行查询。 第二部，创建临时表 语法 --创建临时表 SELECT * INTO #TEMP_REPORT_TABLE FROM BASE --删除临时表，最好判断一下是否为空，在进行删除 IF object_id('tempdb..#TEMP_REPORT_TABLE') IS NOT NULL BEGIN DROP TABLE #TEMP_REPORT_TABLE END 最终优化的就是
1. 用IN来替换OR 下面的查询可以被更有效率的语句替换: 低效: SELECT field1, field1 FROM LOCA TION WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30 高效 SELECT field1, field1 FROM LOCA TION WHERE LOC_IN IN (10,20,30) 2. 连接多个扫描 如果你对一个列和一组有限的值进行比较, 优化器可能执行多次扫描并对结果进行合并连接. 举例: SELECT * FROM LODGING WHERE MANAGER IN (‘BILL GA TES’,’KEN MULLER’); 优化器可能将它转换成以下形式 SELECT * FROM LODGING WHERE MANAGER = ‘BILL GA TES’ OR MANAGER = ’KEN MULLER’; 3. 优化GROUP BY 提高GROUP BY语句的效率, 可以通过将不需要的记录在GROUP BY之前过滤掉.下面两个查询返回相同结果但第二个明显就快了许多. 低效: SELECT JOB , A VG(SAL) FROM EMP GROUP JOB HA VING JOB = ‘PRESIDENT’OR JOB = ‘MANAGER’ 高效: SELECT JOB , A VG(SAL) FROM EMP WHERE JOB = ‘PRESIDENT’OR JOB = ‘MANAGER’ GROUP JOB 4. 用>= 替代> 如果DEPTNO上有一个索引, 高效: SELECT * FROM EMP WHERE DEPTNO >=4 低效: SELECT * FROM EMP WHERE DEPTNO >3 5. 用表连接替换EXISTS 通常来说, 采用表连接的方式比EXISTS更有效率
SQL 高性能查询优化语句，一些经验总结 1.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null; 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num = 0; 2.应尽量避免在 where 子句中使用!=或$amp; 3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num=10 or num=20; 可以这样查询： select id from t where num=10 union all select id from t where num=20; 4.in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如： select id from t where num in(1,2,3) 对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3; 5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。 见如下例子： SELECT * FROM T1 WHERE NAME LIKE ‘%L%’; SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’; SELECT * FROM T1 WHERE NAME LIKE ‘L%’; --第三个查询能够使用索引来加快操作 即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。 6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描： select id from t where num=@num; 可以改为强制查询使用索引：
我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下为笔者学习、摘录、并汇总部分资料与大家分享！ （1）选择最有效率的表名顺序(只在基于规则的优化器中有效)：ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写 在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那 个被其他表所引用的表. （2） WHERE子句中的连接顺序．： ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须 写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾. （3） SELECT子句中避免使用‘ * ‘： ORACLE 在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 （4）减少访问数据库的次数： ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等； （5）在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 （6）使用DECODE函数来减少处理时间： 使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表. （7）整合简单,无关联的数据库访问： 如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它 们之间没有关系) （8）删除重复记录： 最高效的删除重复记录方法 ( 因为使用了ROWID)例子： DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID) FROM EMP X WHERE X.EMP_NO = E.EMP_NO); （9）用TRUNCATE替代DELETE： 当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前 的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用TRUNCATE时, 回滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的资源被调用,执行时间也会很短. (译者按: TRUNCATE只在删除全表适 用,TRUNCATE是DDL不是DML) （10）尽量多使用COMMIT： 只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求也 会因为COMMIT所释放的资源而减少: COMMIT所释放的资源: a. 回滚段上用于恢复数据的信息. b. 被程序语句获得的锁 c. redo log buffer 中的空间 d. ORACLE为管理上述3种资源中的内部花费
高级SQL优化(一) SQL优化简介 一般在应用中，糟糕的SQL语句是造成系统性能低下的最主要原因，例如大小写的不统一、同样的SQL语句不同的写法等。而且，随着数据量的增加，情况会变得越来越严重。（题外话：优秀的Oracle数据库优化人才，是任何公司都稀缺的） SQL优化又称SQL调节，其步骤一般包括： SQL调节的目标 SQL调节包括三大目标：降低负载、均衡负载和并行化负载。 l降低负载：即寻找更高效的途径来完成相同的功能 如某个非大表(小于2000万行数据数据或小于2G大小的单表)，常规查询需要访问的数据实践中90%情况下是不会超过20%的，此时建立合理的索引是有效的方法之一 l均衡负载：即应该把任务分时段均衡调度 如一般系统白天是访问高峰，如果此时备份任务、批处理任务或报表数据抽取任务也挤在这个时段则易
造成负载峰 值现象，正确的做法应该是把备份任务、批处理任务和报表数据抽取任务放到晚上进行处理，或采用并行化策略 l并行化负载：即大数据量的查询访问需要使用并发策略 如在数据仓库环境中应该多使用并发策略，此举可以明显减少响应时间 SQL优化阶段 使用OEM发现顶级SQL
在OEM中，选择性能->其它监视链接->定级活动，如下图：
不要用*代替所有列名 指定仅仅需要的列名与使用*对比： 时间：359/1327=27.05% CUP耗费: 4092121327/6413227637=63.81%
IO耗费： 29601/110117=26.88% 可见大幅降低I/O从而降低响应时间！ SQL优化技巧 使用TRUNCATE代替DELETE Oralce执行DELETE后会使用UNDO表空间存放被删除的信息以便恢复，如果之后用户使用ROLLBACK而不是COMMIT，则Oralce将利用该UNDO表空间中的数据进行恢复。当使用TRUNCATE时，Oracle不会将删除的数据放入UNDO表空间，因而速度要快很多。当要删除某个表中的全部数据时，应该使用TRUNCATE而不是不带WHERE条件的DELETE。语法如下： TRUNCATE TABLE table_name [DROP|REUSE STORAGE] DROP STORAGE为默认的方式，表示收回被删除的表空间 REUSER STORAGE表示保留被删除的空间以供该表的新数据使用 应用开发中，可以编写一个子程序让其动态的清除空表，以供调用。 默认PCTFREE为10，假定为5,high-water mark是一个存储段分配多少存储器的标记。