informix查询语句(select)的优化.pdfVIP

查询语句（SELECT）的优化 程序设计中的一个著名定律是 20 ％的代码用去了80 ％的时间，在数据库应用程序中也同样 如此。数据库应用程序的优化通常可分为两个方面：源代码的优化和 SQL 语句的优化。源 代码的优化在时间成本和风险上代价很高；另一方面，源代码的优化对数据库系统性能的提 升收效有限。 许多程序员认为查询优化是 DBMS （数据库管理系统）的任务，与程序员所编写的SQL 语 句关系不大，这是错误的。一个好的查询计划往往可以使程序性能提高数十倍。查询计划是 用户所提交的 SQL 语句的集合，查询规划是经过优化处理之后所产生的语句集合。DBMS 处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给 DBMS 的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理 并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。虽 然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的 SQL 语句是系统 优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户 所写语句的优劣至关重要。 1、对查询语句进行优化的理由 下列几方面的原因是我们进行 SQL 语句优化的理由： ◆ SQL 语句是对数据库(数据)进行操作的惟一途径； ◆ SQL 语句消耗了 70%~90% 的数据库资源； ◆ SQL 语句独立于程序设计逻辑，相对于对程序源代码的优化，对 SQL 语句的优化在时间 成本和风险上的代价都很低； ◆ SQL 语句可以有不同的写法； ◆ SQL 语句易学，难精通。 从大多数数据库应用系统的实例来看，查询操作在各种数据库操作中所占据的比重最大，而 查询操作所基于的 SELECT 语句在 SQL 语句中又是代价最大的语句。 2 、查询语句（SELECT）的优化建议 （1）、合理使用索引：where 子句中变量顺序应与索引字键顺序相同。 如：create index test_idx on test(bdh, rq, xz) 　　 索引字键顺序：首先是保单号 bdh ，其次是日期rq ，最后是险种xz ，所以where 子句 变 量 顺 序 应 是 where bdh=“P1234”and rq=“06/06/1999”and xz=“DAA”,不 应 是 where xz=“DAA” and rq=“06/06/1999” and bdh =“P1234”这样的不按索引字键顺序写法。 （2 ）、将最具有限制性的条件放在前面，大值在前，小值在后。 　 　如：where colA=10000 AND colA=1　效率高 　　 where colA=1 AND colA=10000 效率低 （3 ）、避免采用MATCHES 和 LIKE 通配符匹配查询 通配符匹配查询特别耗费时间。即使在条件字段上建立了索引，在这种情况下也还是采用顺 序扫描的方式。 例如语句：SELECT ＊ FROM customer WHERE zipcode MATCHES “524*” 可 以 考 虑 将 它 改 为 SELECT ＊ FROM customer WHERE ZipCode=“524999” AND ZipCode =“524000” ，则在执行查询时 就会利用索引来查询，显然会大大提高速度。 （4 ）、避免非开始的子串 例如语句：SELECT ＊ FROM customer WHERE zipcode[2 3] “24” ，在where 子句中采用 了非开始子串，因而这个语句也不会使用索引。 （5 ）、避免相关子查询 一个字段的标签同时在主查询和 where 子句中的查询中出现，那么很可能当主查询中的字段 值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免 子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。 例如：将下面的语句 select bdh,bf from TabA where item IN (select item form TabB where TabB.num=50) 改为：select bdh,bf from TabA, TabB where TabA.item=TabB.item AND TabB.num=50 （6 ）、避免或简化排序 应当简化或避