参考资料--Informix查询语句(SELECT)的优化.docVIP

查询语句（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）、避免或简化排序  ◆ 索引中不包括一个或几个待排序的字段； ◆ group?by或order?by子句中字段的次序与索引的次序不一样；  排序的字段来自不同的表。  （7）、消除对大型表行数据的顺序存取 3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的字段进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。 where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作： SELECT?＊?FROM?orders?WHERE?(cust_num=126??AND?order_num1001)?OR?????order_num=1008 cust_num和order_num上建有索引，但是在上面的语句中优化器还是