数据库SQL查询处理及其优化方法的研究
1 绪论
到如今，几乎所有应用系统的开发都离不开数据库，通过查询数据库就可以有效的得到想要的数据。但是，现实中许多数据库开发人员在利用一些前端数据库开发工具开发数据库应用程序时只注重用户界面的华丽，并不注重查询效率，导致所开发出来的应用系统中查询时间长，响应速度慢，甚至查询结果不够准确等，系统工作效率低下，资源浪费严重。究其原因，一是硬件设备（如CPU、磁盘）的存取速度跟不上，内存容量不够大；另一方面是数据查询方法不适当，抑或是没有进行数据查询优化。
许多数据库开发人员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是不对的，一个好的查询方法往往可以使程序性能提高数十倍。在实际的数据库产品（如Oracle、Sybase、SQL Server 2000等）的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表中所得到的信息来估计不同的查询方法代价，然后选择一个较优的规则。虽然现在的数据库产品在数据查询优化方面已经做得越来越好，但由于用户提交的SQL语句是查询优化的基础，因此用户所写语句的优劣至关重要。
2 关系数据库查询处理
要研究查询优化就必须知道数据库查询处理过程，本节阐述了关系数据库（RDBMS）的查询处理步骤，并介绍了查询处理的任务是把用户提交给RDBMS的查询语句转换为高效的执行计划。
2.1 查询处理步骤
RDBMS查询处理过程可以分为四个阶段：查询分析、查询检查、查询优化和查询执行，如图2-1所示。
(1) 查询分析
查询分析是查询处理的第一个阶段，主要任务是对查询语句进行扫描、词法分析和语法分析。从查询语句中识别出语言符号，SQL关键字、属性名和关系名等，并且进行语法检查和语法分析，即判断查询语句是否符合SQL语法规则。
(2) 查询检查
查询检查是根据数据字典对合法的SQL 查询语句进行语义检查，即检查语句中的数据库对象，如属性名、关系名，是否存在和是否有效等。还要根据数据字典中的用户权限和完整性约束对用户的存取权限进行检查。如果该用户没有相应的访问权限或违反了完整性约束，就拒绝执行该查询操作。检查通过后便把SQL 查询语句转换成等价的关系代数表达式。RDBMS 一般都用查询树（query tree ）,也称为语法分析树，来表示扩展的关系代数表达式。这个过程中要把数据库对象的外部名称转换为内部表示。
图2-1 查询处理步骤
(3) 查询优化
每个查询语句都会有很多可供选择的执行策略和操作算法，查询优化（query optimization ）词法分析 语法分析 语义分析
符号名转换
安全性检查
完整性检查 查询树（query tree ）
代数优化
物理优化等
执行策略描述
代码生成
查询计划的执行代码
数据库 数据字典
查询语句
查询分析 查询检查 查询优化 查询执行
就是选择一个高效的查询处理策略。查询优化有许多种方法。按照优化的层次一般可以分为代数优化和物理优化。代数优化是指关系代数表达式的优化，即按照一定的规则，改变代数表达式中操作的次序和组合，使查询执行更高效；物理优化则是指存取路径和底层操作算法的选择。选择的依据可以是基于规则的，也可以基于代价的，还可以基于语义的。
实际RDBMS中的查询优化器都综合了运用了这些优化技术，以获得最好的查询优化效果。
(4) 查询执行
查询执行就是依据优化器得到的执行策略生成查询计划，由代码生成器（code generator）生成执行这个查询计划的代码。
2.2 实现查询操作的算法示例
选择操作和连接操作是查询操作的两个典型操作，每一种操作有多种执行这个操作的算法，下面探讨实现这两种操作的几个主要算法。
2.2.1选择操作的实现
众所周知SELECT语句功能十分强大，有许多选项，因此实现的算法和优化策略也很复杂。下面以简单的选择操作为例讲述典型的实现方法。
例1 Select * from student where<条件表达式>；
考虑<条件表达式>的几种情况：
C1：无条件；
C2：Sno=‘20XX15121’；
C3：Sage>20；
C4: Sdept=‘CS’ AND Sage>20；
（1）简单的全表扫描方法
对查询的基本表顺序扫描，逐一检查每个元组是否满足选择条件，把满足条件的元组作为结果输出。对于小表，这种方法简单有效。对于大表顺序扫描十分费时，效率很低。（2）索引（或散列）扫描方法
如果选择条件中的属性上有索引（例如B+树索引或Hash索引），可以用索引扫描方法。通过索引先找到满足条件的元组主码或元组指针，再通过元组指针直接在要查询的基本表中
找到元组。
例1-C2 以C2为例，Sno=‘20XX15121’，并且Sno上有索引，则可以通过使用索引得到Sno为‘20XX15121’元组的指针，然后通过元组指针在student表中检索等到该学生。
例1-C3 以C3为例，Sage>20，并且Sage上有B+树索引，则可以使用B+树索引找到Sage=20的索引项，以此为入口在B+树的顺序集上得到Sage>20的所有元组指针，然后通过这些元组指针到student表中检索所有年龄大于20的学生。
例1-C4 以C4为例，Sdept=‘CS’AND Sage>20,如果Sdept和Sage上都有索引，一种算法是：分别用上面的两种方法分别找到Sdept=‘CS’的一组元组指针和Sage>20的另一组元组指针，求这两组指针的交集，再到student表中检索，就得到计算机系年龄大于20的学生。
另一种算法是：找到Sdept=‘CS’一组元组指针，通过这些元组指针到student表中检索，并对得到的元组检查另一些选择条件是否满足，把满足条件的元组作为结果输出。
2.2.2 连接操作的实现
连接操作是查询处理中最耗时的操作之一。不失一般性，本文只讨论等值连接最常用的实现算法。
例2 SELECT * FROM Student，SC WHERE Student.Sno=SC.Sno;
（1）嵌套循环方法
这是最简单可行的算法。对外层循环（student）的每一个元组（s）,检索内层循环（SC）中的每一个元组（sc）,并检查这两个元组在连接属性（sno）上是否相等。如果满足连接条件，则串接后作为结果输出，直到外层循环表中的元组处理完为止。
（2）排序-合并方法
这也是最常用的算法，尤其适合连接的诸表已经排好序的情况。
用排序-合并连接方法的步骤是：
①如果连接的表没有排好序，首先对Student表和SC表按连接属性Sno排序；
②取student中的第一个Sno，依次扫描SC表中具有相同的Sno的元组；把它们连接起来；
③当扫描到Sno不相同的第一个SC元组时，返回Student表扫描它的下一个元组；再扫描SC表中具有相同的Sno的元组，把它们连接起来。
重复上述步骤直到Student表扫描完。
这样Student表和SC表都只要扫描一遍。当然，如果2个表原来无序，执行时间要加上对两个表的排序时间。即使这样，对于2个大表，先排序后使用sort-merge join方法执行连接，
总的时间一般仍会大大减少。
（3）索引连接方法
用索引连接方法的步骤是：
①在SC表上建立属性Sno的索引，如果原来没有的话；
②对Student中的每一个元组，由Sno值通过SC的索引查找相应的SC元组；
③把这些SC元组和Student表中的元组连接起来。
循环执行②③，直到Student表中的元组处理完为止。
（4）Hash Join方法
属性作为hash码，用同一个hash函数把R和S中的元组散列到同一个hash文件中。第一步，划分阶段，对包含较少元组的表进行一遍处理，把它的元组按hash函数分散到hash 表的桶中；第二步，试探阶段，也称为连接阶段，对另一表（S）进行一遍处理，把S的元组散列到适当的hash桶中，并把元组与桶中所有来自R并与之相匹配的元组连接起来。
3SQL查询处理优化方法
查询优化在关系数据库系统中有着非常重要的地位，关系数据库系统和非过程化的SQL 之所以能取得巨大的成功，关键得益于查询优化技术的发展。关系查询优化是影响RDBMS 性能的关键因素。
查询优化既是RDBMS实现的关键又是关系数据库的优点所在。它减轻了用户选择存取路径的负担。用户只要提出“干什么”，不必指出“怎么干”。对比一下非关系系统中的情况：用户使用过程化的语言表达查询要求，执行何种记录级的操作，以及操作的序列是由用户而不是由系统来决定的。因此用户必须了解存取路径，系统要提供用户选择存取路径的手段，查询效率由用户的存取策略决定。如果用户做了不当的选择，系统是无法对此加以改进的。这就要求用户有较高的数据库技术和程序设计水平。下面介绍几种常用的查询优化方法。
3.1 基于索引的优化
（1）索引定义
索引是一个单独的、物理的数据库结构。它是根据表中一列或若干列，按照一定顺序建立的列值与记录行之间的对应关系表。
索引是依赖于表建立的，它包含索引键值及指向数据所在页面和行的指针。一个表的存储是由两部分组成的，一部分用来存放表的数据页面，另一部分存放索引页面，索引就存放
在索引页面上。通常，索引页面相对于数据页面来说要小得多。当进行数据检索时，系统先搜索索引页面，从中找到所需数据的指针，然后再直接通过指针从数据页面中读取数据。
索引可以提供对一个表中的数据的有效访问，它可以用于加速数据的检索和强制唯一性限制。但是，不应该在每一个列上都建立索引，因为构造索引需要占用一定的系统资源，降低更新的速度。而且，插入、删除或更新一个索引列中的数据比非索引列中的数据要花费更长的时间。
（2）索引的作用
索引是加快数据检索的一种数据库结构，使得数据查询时不必扫描整个数据库就能迅速查到想要的数据。具体如下5个方面：
①通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
②可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
③可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
④在使用分组和排序子句进行数据检索时，同样可以减少查询中分组和排序的时间。
⑤通过使用索引，可以在查询的过程中，使用优化器隐藏，提高系统的性能。
（3）索引的类型
如果一个表没有创建索引，则数据行不按任何特定的顺序存储，这种结构称为堆集。在SQL Server 2000的数据库中，按存储结构的不同将索引分为两类：簇索引（Clustered Index）和非簇索引(Nonclustered Index)。
1. 簇索引
簇索引对表的数据行的键值进行排序，然后再存储有用的数据记录。由于簇索引对表中的数据一一进行了排序，因此用簇索引查找数据很快。但由于簇索引将表中的所有数据完全重新排列了，它所需要的空间也就特别大，大约相当于表中数据所占空间的120%。表的数据行只能以一种排序方式存储在磁盘上，所以一个表只能有一个簇索引。
2. 非簇索引
非簇索引具有完全独立于数据行的结构，使用非簇索引不用对表的数据行的键值进行排序。非簇索引的B-树叶节点存储了组成非簇索引的键值和行定位器（从索引行指向数据行的指针称为行定位器），行定位器的结构和存储内容取决于数据的存储方式，如果数据是以索引方式存储的则行定位器中存储的是簇索引的索引键；如果不是以索引方式存储的，这种方式称为堆存储方式（Heap Structure）,则行定位器中存储的是指向数据行的指针。非簇索引将行定位器的键值用一定的方式排序，这个顺序与表的行在数据页中的排序是不匹配的。
由于非簇索引使用索引页存储，因此簇索引需要更多的空间，且检索效率较低。但一个
表只能建一个簇索引，当用户需要建立多个索引时，就需要使用非簇索引了。从理论上讲，一个表最多可以建248个非簇索引。
对于何时使用簇索引、何时使用非簇索引如表3-1所示
表3-1使用簇索引或非簇索引的时机
动作描述使用簇索引使用非簇索引列经常被分组排序应应
返回某范围内的数据应不应
一个或极少不同值不应不应
小数目的不同值应不应
大数目的不同值不应应
频繁更新的列不应应
外键列应应
主键列应应
频繁修改索引列不应应
（4）索引的建立与删除
一般来说，建立与删除索引由数据库管理员DBA或表的属主（owner），即建表的人负责完成。系统在存取数据时会自动选择合适的索引作为存取路径，用户不必也不能显式地选择索引。
1.建立索引
在SQL语言中，建立索引使用CREATE INDEX语句，其一般格式为：
CREATE [UNIQUE] [CLUSTER] INDEX <索引名>
ON <表名> （<列名>[<次序>][，<列名>[<次序>]]…）
其中，<表名>是要建索引的基本表的名字。索引可以建立在该表的一列或多列上，各列名之间用逗号分隔。每个<列名>后面还可以用<次序>指定索引值的排列次序，可选ASC（升序）或DESC（降序），缺省值为ASC。
UNIQUE表明此索引的每一个索引值只对应唯一的数据记录。
CLUSTER表示要建立的索引是聚簇索引。
例1 CREATE CLUSTER INDEX Stusname ON Student(Sname);
这条语句是在Student表的Sname（姓名）列上建立一个聚簇索引，而且Student表中的记录将会按照Sname值的升序存放。
例2 CREATE UNIQUE INDEX Stusno ON Student(Sno);
CREATE UNIQUE INDEX Couo ON Student(o);
CREATE UNIQUE INDEX So ON Student(Sno ASC,o DESC);
这三条语句是为学生-课程数据库中的Student，Course，SC 3个表建立索引。其中Student 表按学号升序建唯一索引，Course表按课程号升序建唯一索引，SC表按学号升序和课程号降序建唯一索引。
2.删除索引
索引一经建立，就由系统使用和维护它，不需用户干预。建立索引是为了减少查询操作的时间，但如果数据增删改频繁，系统会花费很多时间来维护索引，从而降低了查询效率。这时可以删除一些不必要的索引。
在SQL中，删除索引使用DROP INDEX 语句，其一般格式为
DROP INDEX <索引名>；
例3 删除Student表的Stusname索引。
DROP INDEX Stusname;
删除索引时，系统会同时从数据字典中删去有关该索引的描述。
3.2 SQL语句优化
使用索引可以有效的提高查询速度，但是SQL语句是对数据库操作的唯一途径，程序的执行最终都归结为SQL语句的执行，所以SQL语句的执行效率对数据库系统的性能起了决定性的作用。所以我们不但要会写SQL语句，还要写出性能优良的SQL语句。
对于优化SQL语句，本主要就避免相关子查询、where字句的优化以及几个表的连接条件这几个方面进行阐述。
3.2.1 where字句优化
在where子句中优化SQL语句是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子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。
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.应尽量避免在where子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
SELECT * FROM T1 WHERE F1/2=100
应改为:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’
应改为:
SELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
应改为:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
6.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行
全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'20XX-11-30')=0--‘20XX-11-30’生成的id 应改为:
select id from t where name like 'abc%'
select id from t where createdate>='20XX-11-30' and createdate<'20XX-12-1'
7.不要在where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
8.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
9.很多时候用exists是一个好的选择：
elect num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
3.2.2 避免相关子查询
如果在主查询和WHERE子句中的查询中同时出现了一个列的标签，这样就会使主查询的列值改变后，子查询也必须重新进行一次查询。因为查询的嵌套层次越多，查询的效率就越低，所以我们应当避免子查询。如果无法避免，就要在查询的过程中过滤掉尽可能多的子查询。
例如首先使用子查询实现查询要求（查询开销为87%）
SELECT Sname
FROM STUDENT
WHERE EXISTS(SELECT * FROM TABLE C
WHERE CARDID=C.CARDID AND BALANCE=200)
然后不使用子查询实现查询要求（查询开销为13%）
SELECT Sname
FROM TABLE S
JOIN TABLE C ON S.CARDID=C.CARDID
WHERE BALANCE=200
如何优化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.1、数据库及SQL代码优化方案 （1）每周检查统计信息是否及时更新。 （2）每周检查各索引是否有效。 （3）每周检查分区是否正确。 （4）每周检查执行计划是否正确。 （5）每天检查RAC和ASM是否正常运行。 （6）每天检查相关日志是否正常备份。 （7）每天检查相关文件系统和表空间的占用率是否在国家税务总局规定的阀值以下。 （8）在每月申报高峰等业务繁忙期采样并找出消耗I/O资源和CPU资源较多的SQL语句。 （9）分析上述SQL语句，与软件服务商充分沟通后，提出优化建议。 （10）在每月申报高峰期每隔15分钟检查一次数据库连接数，发现异常及时处理。 1.1.1、系统数据库索引、表分区和对象优化方案 数据库对象的优化主要包括：表、索引和sequence等对象，通过优化对象参数、调整对象属性（例如分区表、分区索引、反转索引等等）等方法来实现对数据库对象的优化改造。 1.1.1.1表和索引并行参数优化 数据库的表和索引的并行参数值的设置对相关的sql语句的执行计划会造成影响，表和索引的degree值大于1，执行计划就偏向于使用全表和全索引扫描，另外如果并行参数值过大，短时间内也会对主机和数据库的资源造成很大的压力，因此在oltp的数据库下建议将表和索引的degree值设为1。 1.1.1.2热点大表的分区改造 对访问量很大、表的记录数很多、存在热块争用的表，可以考虑对表和索引进行适当的分区改造，分散访问压力，提高数据访问的性能。 对以下表的记录数超过1000万并且记录数持续增长的大表，建议进行分区
改造（地区+时间）： 1.1.1.3分区索引的清理 对最近30天数据库分区索引访问情况进行统计，对访问次数为0的分区索引和应用部门进行确认，若确认为多余的索引，建议进行删除清理。 1.1.1.4Sequence序列优化 加大sequence 的 cache，并使用noorder选项。在RAC中经常会遇到SQ 锁等待，这是因为在RAC环境下，sequence也成为全局性的了，不同节点要生成序列号，就会产生对sequence资源的争用。而目前大多数系统中，sequence 大多数被作为主键发生器来使用，使用的频率十分高，在RAC环境中，需要设置较大的 sequence cache，否则会造成较为严重的争用，从而影响业务。 1.1.2、SQL硬解析优化方案 1.1. 2.1相关知识点介绍 1.1. 2.1.1Oracle的硬解析和软解析 Oracle对sql的处理过程：当发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程： 1、语法检查(syntax check) 检查此sql的拼写是否语法。 2、语义检查(semantic check) 诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。 3、对sql语句进行解析(prase) 利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。 4、执行sql，返回结果(execute and return) 其中，软、硬解析就发生在第三个过程里。 Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache
SQL SERVER性能优化综述 近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在 网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或 者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以 前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能 性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能 有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能 调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效 率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组 成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三
第四章关系系统及其查询优化 习题 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数据逻辑独立性。当对基本关系进行理论上信息不受损的任何改变时，应用程序和终端活动都保持逻辑上的不变性。
SQL数据库优化方法
目录 1 系统优化介绍 (1) 2 外围优化 (1) 3 SQL优化 (2) 3.1 注释使用 (2) 3.2 对于事务的使用 (2) 3.3 对于与数据库的交互 (2) 3.4 对于SELECT *这样的语句， (2) 3.5 尽量避免使用游标 (2) 3.6 尽量使用count(1) (3) 3.7 IN和EXISTS (3) 3.8 注意表之间连接的数据类型 (3) 3.9 尽量少用视图 (3) 3.10 没有必要时不要用DISTINCT和ORDER BY (3) 3.11 避免相关子查询 (3) 3.12 代码离数据越近越好 (3) 3.13 插入大的二进制值到Image列 (4) 3.14 Between在某些时候比IN 速度更快 (4) 3.15 对Where条件字段修饰字段移到右边 (4) 3.16 在海量查询时尽量少用格式转换。 (4) 3.17 IS NULL 与IS NOT NULL (4) 3.18 建立临时表， (4) 3.19 Where中索引的使用 (5) 3.20 外键关联的列应该建立索引 (5) 3.21 注意UNion和`UNion all 的区别 (5) 3.22 Insert (5) 3.23 order by语句 (5) 3.24 技巧用例 (6) 3.24.1 Sql语句执行时间测试 (6)
1系统优化介绍 在我们的项目中，由于客户的使用时间较长或客户的数据量大，造成系统运行速度慢，系统性能下降就容易造成数据库阻塞。这是个非常痛苦的事情，用户的查询、新增、修改等需要花很多时间，甚至造成系统死机的现象。速度慢的原因主要是来自于资源不足。 数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来最多只占数据库系统性能提升的40%左右(我将此暂时称之为外围优化)；其余大部分系统性能提升来自对应用程序的优化，对于应用程序的优化可以分为对源代码的优化及数据库SQL语句的优化。在本文档只介绍外围优化及SQL语句的优化，对于源代码的优化需要相关方面的专家，形成统一的规范。 一个数据库系统的生命周期可以分成：设计、开发和成品三个阶段。在设计阶段进行数据库性能优化的成本最低，收益最大。在成品阶段进行数据库性能优化的成本最高，收益最小。规范的代码和高性能的语句，功在平时，利在千秋。 2外围优化 1、将操作系统与SQL数据库的补丁打到最高版本，WIN2003最高补丁是SP4， SQL SERVER2000最高补丁是SP4(版本号：2039)。 2、在服务器上不要安装与VA程序任何无相关的软件，甚至一些与VA运行 无关的服务都可以停掉。一般只安装SQL数据库、VA服务端服务及杀毒 软件。 3、杀毒软件避免对大文件进行扫描，特别是数据库（MDF和LDF）文件，一 定要从杀毒软件的范围内排除掉。 4、在进行服务器分区时，分区不要太多，两三个分区就可以了。分区最好 都使用NTFS格式。
一、实验目的 1.熟悉查询查询处理的过程； 2.掌握查询优化的概念，理解查询优化的必要性； 3.了解数据库的查询计划； 4.掌握查询代价的分析方法，并且能通过配置参数或者修改SQL语句来降低 查询代价。 二、实验环境 SQL Server 三、实验学时 2学时 四、实验要求 1）求选修了00002号课程的学生姓名。用SQL表达： SELECT Student.Sname FROM Student，SC WHERE Student.Sno=SC.Sno AND https://www.doczj.com/doc/dc14680670.html,o=‘00002’ 2）三种实现方法： Q1=πSname(σStudent.Sno=SC.Sno∧https://www.doczj.com/doc/dc14680670.html,o='2' (Student×SC)) Q2=πSname(σhttps://www.doczj.com/doc/dc14680670.html,o='2' (Student SC)) Q3=πSname(Student σhttps://www.doczj.com/doc/dc14680670.html,o='2'(SC)) 3）要求：本实验旨在说明查询优化的必要性，只要求把法一Q1与法二Q2和法三 Q3比较，从而说明查询优化的重要性 五、实验内容及步骤 （一）实验数据的准备 -- 1.创建数据库 create database stu_optimization ON ( NAME = stu_opti, FILENAME = 'E:\stu_opti\stu_opti.mdf', SIZE = 100, MAXSIZE = 500, FILEGROWTH = 10 ) LOG ON ( NAME = 'stu_opti_log', FILENAME = 'E:\stu_opti\stu_opti_log.ldf', SIZE = 50MB,
数据库优化查询计划的方法 数据库系统是管理信息系统的核心，基于数据库的联机事务处理（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操作）的列上建立索引；
目录 一、关于SQL查询效率，100w数据，查询只要1秒。 (2) 二、SQL提高查询效率注意事项 (4) 三、提高SQL查询效率（要点与技巧） (9) 四、建立索引与不建立索引的一个查询效率分析： (10) 五、如何提高SQL语言的查询效率 (11) 六、使用SQL语句时应注意以下几点 (13) 七、ORACAL中的应用案例分析 (14)
一、关于SQL查询效率，100w数据，查询只要1秒。 ●机器情况：p4: 2.4 ●内存：1 G ●Os：windows 2003 ●数据库：ms sql server 2000 ●目的：查询性能测试,比较两种查询的性能 SQL查询效率step by step： step 1. -- 建表 create table t_userinfo ( userid int identity(1,1) primary key nonclustered, nick varchar(50) not null default '', classid int not null default 0, writetime datetime not null default getdate() ) go -- 建索引 create clustered index ix_userinfo_classid on t_userinfo(classid) go step 2. --插入数据，耗时08:27 ，需要耐心等待 declare @i int declare @k int declare @nick varchar(10) set @i = 1 while @i<1000000 begin set @k = @i % 10 set @nick = convert(varchar,@i) insert into t_userinfo(nick,classid,writetime) values(@nick,@k,getdate()) set @i = @i + 1
MySQL数据库性能（SQL）优化方案本文探讨了提高MySQL 数据库性能的思路，并从8个方面给出了具体的解决方法。 1、选取最适用的字段属性 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN 来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 2、使用连接（JOIN）来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示： DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
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;
关于数据库优化方面的文章很多，但是有的写的似是而非，有的不切实际，对一个数据库来说，只能做到更优，不可能最优，并且由于实际需求不同，优化方案还是有所差异，根据实际需要关心的方面（速度、存储空间、可维护性、可拓展性）来优化数据库，而这些方面往往又是相互矛盾的，下面结合网上的一些看法和自己的一些观点做个总结。 一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP(联机事务处理系统)和OLAP(联机分析处理系统)。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式：第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。 2、合理的冗余 完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。 冗余可以是冗余数据库、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。 冗余可以是为了编程方便而增加，也可以是为了性能的提高而增加。从性能角度来说，冗余数据库可以分散数据库压力，冗余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。 3、主键的设计 主键是必要的，SQL SERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键，所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的，这个在下面索引的叙述。 在有多个键的表，主键的选择也比较重要，一般选择总的长度小的键，小的键的比较速度快，同时小的键可以使主键的B树结构的层次更少。 主键的选择还要注意组合主键的字段次序，对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般应该选择重复率低、单独或者组合查询可能性大的字段放在前
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 SERVER数据库优化方案 微软公司的SQL SERVER 是一个功能完备的数据库管理系统，它提供了完整的关系数据库创建、开发和管理功能。现社会信息技术的快速发展，对数据库技术的要求也越来越高，SQL SERVER数据库在信息化的过程中得到了广泛的应用。 第一章数据库系统概述 从20世纪60年代开始到现在，数据库技术经过了30多年的发展。在这30多年的历程中，在数据库技术的理论研究和系统开发上取得了辉煌的成就，确立了数据技术在现代计算机系统中不可或缺的地位。成为现代信息科学与技术的重要组成部分以及计算机数据处理和信息管理系统的核心。 1．1 基本概念 与数据库技术密切相关的基本概念包括：数据、数据库、数据库管理系统和数据库系统四大概念。 1.数据（Data） 数据是对客观事物的一种描述，是由能被计算机识别与处理的数值、字符等符号构成的集合，即数据是指描述事物的符号记录。 广义地说，数据是一种物理符号的序列，用于记录事物的情况，是对客观事物及其属性进行的一种抽象化及符号化的描述。数据的概念应包括数据的内容和形式两个方面。数据的内容是指所描述的客观事物的具体特性，也就是通常所说的数据的“值”；数据的形式则是指数据内容所存储的具体形式，即数据的“类型”。故此，数据可以用数据类型和值来表示。 2.数据库（Data Base，DB） 数据库是指长期存储在计算机内部、有组织的、可共享的数据集合，即在计算机系统中按一定的数据模型组织、存储和使用的相关联的数据集合成为数据库。 数据库中的数据按照一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性、易扩展性、集中性和共享性，以文件的形式存储在存储介质上的。数据库中的数据由数据库管理系统进行统一管理和控制，用户对数据库进行的各种数据操作都是通过数据
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语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。 在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。 二、SQL语句编写注意问题 下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。
1. 操作符优化 (a) IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。但是用IN的SQL性能总是比较低的，从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别： ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。 推荐方案：在业务密集的SQL当中尽量不采用IN操作符，用EXISTS 方案代替。 (b) NOT IN操作符 此操作是强列不推荐使用的，因为它不能应用表的索引。 推荐方案：用NOT EXISTS 方案代替 (c) IS NULL 或IS NOT NULL操作（判断字段是否为空） 判断字段是否为空一般是不会应用索引的，因为索引是不索引空值的。不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是
高级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是一个存储段分配多少存储器的标记。