Database 版 (精华区)

发信人: lizhenguo (夸父·追日), 信区: Database
标  题: 18
发信站: 哈工大紫丁香 (2001年09月26日18:44:02 星期三), 站内信件

 bbs.hit.edu.cn
PowerBuilder专栏
[回到开始][上一层][下一篇]
----------------------------------------------------------------------------
----
发信人: carsam (独自偷...), 信区: Database
标 题: PowerBuilder应用开发系列讲座(18)
发信站: 逸仙时空 Yat-sen Channel (Wed Jan 5 11:39:38 2000), 站内信件
PowerBuilder应用开发系列讲座(18)
----------------------------------------------------------------------------

----
优化数据库查询
使用PowerBuilder编程时会大量用到数据库查询语句。对于一条复杂的查询语句来说,对

相同查询条件的实现一般总可以有多种不同的表达方法,而不同的表达会使数据库的响应

速度大相径庭。据统计,约有90%的性能问题是由于程序员或用户使用了不恰当的查询语

句造成的,因此提高书写SQL语句的质量对软件性能的提高有很大关系。然而查询语句的

好坏往往是同实际运行系统的数据库结构、记录的数量等具体情况有关的,我们无法只用

几条简单的普遍适用的规律来总结优化查询语句。不过我们首先应当对数据库管理系统

最基本的工作规律有一些了解,这样才能使我们在对查询进行时优化有所根据。
由于SQL语言是面向结果而不是面向过程的查询语言,所以一般支持SQL语言的大型关系型

数据库都需要使用一个基于成本的优化器,为即时查询提供一个最佳的执行策略。对于优

化器,输入是一条查询语句,输出是一个执行策略。这个执行策略是执行这个查询所需要

的一系列步骤。数据库的反应速度经常就体现在这一个优化算法上。不同的查询策略和

查询步骤可使服务器的反应不同,因此采用适当的查询策略可使系统性能大大提高。
优化器的优化基于用户对所查询表的内容和其他一些与服务器有关的因素,如Cache大小

、Cache策略、I/O大小等。一般来说硬盘访问是成本最高的操作,因此对用户来讲,使优

化器对字段索引进行操作是优化查询的关键。
SQL查询语句都可以有很多种执行策略,优化器将估计出全部的执行方法中所需时间最少

的也就是所谓成本最低的一种方法。一般来讲,最为重要的选择就是使用什么索引和采用

何种表的连接手段,而所有优化的进行都是基于用户所使用的查询语句中的where子句。

优化分类
优化器对where子句中的优化分为以下几类:
1.搜索参数
搜索参数的核心就是数据库能否使用表中字段的索引来查询数据,而不必直接查询记录中

的数据。如带有=、＜、＞、＞=、＜=等操作符的条件查询就可以直接使用索引。
如下列条件是搜索参数:
id = "T0001",salary＞30000,a = 1 and c = 7。
而下列则不是搜索参数:
salary = commission,dept != 10,salary *12 ＞= 30000,a = 1 or c = 7。
优化器有时可以将非搜索参数转化为搜索参数,如:
将SELECT name FROM employee WHERE salary BETWEEN $10000 AND $15000
转化为:SELECT name FROM employee WHERE salary ＞= $10000 AND salary ＜= $150

00 将SELECT name FROM employee WHERE name like "a%"
转化为:SELECT name FROM employee WHERE name ＞= "a" AND name＜"b"
将SELECT name FROM employee WHERE salary ＞ $3000 * 12
转化为:SELECT name FROM employee WHERE salary ＞ $36000
因此我们在查询中应当提供一些冗余的搜索参数,使优化器有更多的选择余地。如title

和titleauthor两张表是一对多的关系,同样的查询条件我们有以下三种表现方法:
●SELECT title_id, title FROM titles, titleauthor
WHERE title.title_id = titleauthor.title_id
AND titleauthor.title_id = ‘T81002'
●SELECT title_id, title FROM titles, titleauthor
WHERE title.title_id = titleauthor.title_id
AND title.title_id = ‘T81002'
●SELECT title_id, title FROM titles, titleauthor
WHERE title.title_id = titleauthor.title_id
AND title.title_id = ‘T81002'
AND titleauthor.title_id = ‘T81002'
显然三种方法一种比一种要好,因为后者为优化器提供了更多的选择机会。
2.连接条件
在进行查询连接时优化器将所有连接的方法全部列举出来,计算每一种连接的成本,选择

成本最低的一种。如连接时用到的数据无法获得,一般系统会使用平均密度作为依据,估

算可能的命中率。
3.‘或’运算条件
当查询语句中有IN这样的关键词时,优化器将转化其中的内容以OR并列条件。例如:
SELECT * FROM author WHERE au_lname in (‘Berry',‘Densham')
将转化为:
SELECT * FROM author WHERE au_lname = ‘Berry' or au_lname = ‘Densham'
数据库管理系统将对每一个OR从句进行查询,将所有的结果合并后去掉重复项作为最终结

果。
果。
优化技巧
基于对上述数据库优化器的了解,为确保对我们将要执行的查询语句得以进行准确的优化

,我们应注意以下几点:
1.避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary

是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。

例如:
SELECT name FROM employee WHERE salary ＞ 60000
在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整

型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。
2.如果在一个存储过程或触发器中,有表达式的值在编译时无法得到,优化器就只能使用

它的平均密度来估计命中的记录数。例如:
DECLARE @value money
SELECT name FROM employee WHERE salary = @value
这样的命令是可优化的。只是由于@value的值在执行前不知道,它只能使用其平均密度来

估计这条命令将要命中的记录数。
3.避免对搜索参数使用其它数学操作符,如要将
SELECT name FROM employee WHERE SUBSTRING(id, 1, 1) = 'B'
SELECT name FROM emplyee WHERE salary * 12 ＞ 30000
写成为:
SELECT name FROM employee WHERE id like ‘B%'
SELECT name FROM emplyee WHERE salary ＞ 3000
4.避免使用!=或＜＞等这样的操作符,因为这会使系统无法使用索引,而只能直接搜索表

中的数据。例如:
SELECT id FROM employeeWHERE id != 'B%'
优化器将无法通过索引来确定将要命中的行数。
上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,程序员往

往需要反复试验比较不同的语句以得到最佳方案。此外更为重要的是需要数据库管理员

在数据库的服务器一端调整数据库管理系统的参数,以得到更快的响应性能,这就超出了

本文的讨论范围。
--
我想自由自在地飞......
飞过大海...
飞过沙漠...
飞翔在星的夜空......
※ 来源:．逸仙时空 Yat-sen Channel bbs.zsu.edu.cn．[FROM: 202.116.90.29]
----------------------------------------------------------------------------
----
[回到开始][上一层][下一篇]
欢迎访问Cterm主页

--
《列子·汤问》：“夸父不量力，欲追日影，逐之于隅谷之际。渴欲 得饮，赴饮河渭
。河渭不足，将走北饮大泽。未至，道渴而死。”

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.229.154]