Select 查询优化

1.合理使用索引
索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下：
●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。
●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。
●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的"性别"列上只有"男"与"女"两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。
●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。

(1)在下面两条select语句中:

   select * from table1  where  field1<=10000 and field1>=0 ;
   select * from table1  where  field1>=0 and field1<=10000 ;

   如果数据表中的数据field1都>=0,则第一条select语句要比第二条select语句效率高的多，因为第二条select语句的第一个条件耗费了大量的系统资源。
   第一个原则：在where子句中应把最具限制性的条件放在最前面。

(2)在下面的select语句中:
   select * from tab  where  a=… and b=… and c=…;
  若有索引index(a,b,c)，则where子句中字段的顺序应和索引中字段顺序一致。
   第二个原则：where子句中字段的顺序应和索引中字段顺序一致。

以下假设在field1上有唯一索引I1，在field2上有非唯一索引I2。
(3) select field3,field4 from tb where field1='sdf'        快
     select * from tb where field1='sdf'                       慢，
因为后者在索引扫描后要多一步ROWID表访问。

(4) select field3,field4 from tb where field1>= 'sdf'       快
     select field3,field4 from tb where field1> 'sdf'         慢
因为前者可以迅速定位索引。

(5) select field3,field4 from tb where field2 like 'R% '    快
    select field3,field4 from tb where field2 like '%R '    慢，
    因为后者不使用索引。

(6) 使用函数如：
select field3,field4 from tb where upper(field2)='RMN'不使用索引。
如果一个表有两万条记录，建议不使用函数；如果一个表有五万条以上记录，严格禁止使用函数！两万条记录以下没有限制。

(7) 空值不在索引中存储，所以
    select field3,field4 from tb where field2 is[not] null不使用索引。

(8) 不等式如
    select field3,field4 from tb where field2!='TOM'不使用索引。
    相似地，
    select field3,field4 from tb where field2 not in('M','P')不使用索引。

(9) 多列索引，只有当查询中索引首列被用于条件时，索引才能被使用。

(10)  MAX，MIN等函数，如
Select max(field2) from tb使用索引。所以，如果需要对字段取max，min，sum等，应该加索引。
一次只使用一个聚集函数，如：
select "min"=min(field1), "max"=max(field1)  from tb      
不如：select "min"=(select min(field1) from tb) , "max"=(select max(field1) from tb)    

(11) 重复值过多的索引不会被查询优化器使用。而且因为建了索引，修改该字段值时还要修改索引，所以更新该字段的操作比没有索引更慢。

(12) 索引值过大（如在一个char(40)的字段上建索引），会造成大量的I/O开销（甚至会超过表扫描的I/O开销）。因此，尽量使用整数索引。 Sp_estspace可以计算表和索引的开销。

(13) 对于多列索引，order by的顺序必须和索引的字段顺序一致。

(14) 在sybase中，如果order by的字段组成一个簇索引，那么无须做order by。记录的排列顺序是与簇索引一致的。