基于关系数据库的查询优化

一，合理使用索引

        （略） 

二，查询中数学操作符的优化

1，列操作

         where子句中列旁边的任何操作都将导致对表的扫描。如，select * from employee where substring(name,1,1)="w" 应改为select * from employee where name like "w%"

         优化器会用一个在name上的索引来进行查询，从而提高速度。

         避免对where子句中的条件参数使用其他数学表达式，因为where子句中存在一个代数表达式，所以优化器不能使用分布统计信息。如，可以将sql语句select name from employee where salary*10>3000改为select name from employee where salary>300

2，避免使用负逻辑

          任何负逻辑（“!=”“<>”或“not in”“not exit”）都将导致对表扫描。当表较大时，对系统性能有较大的影响。

          对于其余关系操作符，避免有额外的I/O的方法是使用等于符，如，“>=”“<=”或“=”如果是“>”“<”等运算符就要求读一些不必使用的页面。

3，避免语句出现like"%"

          当采用谓词like时，如果以“%”或“_”等通配符时，则sql server不能使用索引和分布页面。例如，应避免出现下列语句情形：

          select * from employee where empname like "%son"

          而应采用下列语句：

          select * from employee where empname like "s%"

三，数据库查询优化技巧

1， 基本查询优化
          在经 常 进 行连接但是没有指定为外键的列上建立索引，而不经常连接的字段则由DBMS的查询优化器自动生成索引.在频繁进行排序或分组(即进行GROUPBY或ORDERBY操作)的列上建立索引。在条 件 表 达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在学生表的“性别”列上只有“男”、“女”两个不同值，因此就无必要建立索引，建立索引不但不会提高查询效率，反而会严重降低更新速度.如果待排序的列有多个，可以在这些列上建立复合索引.
2 ，避免或简化排序
          应当 简 化 或避免对大型表进行重复的排序.当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤，主要的影响因素如下.
（1） 索 引 中不包括一个或几个待排序的列.
（2）G R OUPBY或ORDERBY子句中列的次序与索引的次序不一样.
（3）排 序 的列来自不同的表。为了 避 免 不必要的排序，就要正确地增建索引，合理地合并数据库表(尽管有时可能影响表的规范化，但相对于效率的提高是值得的)。如果排序不可避免，那么应当试图简化它，如缩小排序列的范
围等。
3， 消除对大型表行数据的顺序存取
         在嵌 套 查 询中，对表的顺序存取对查询效率可能产生致命的影响.比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据.避免这种情况的主要方法就是对连接的列进行索引，还可以使用并集来避免顺序存取，尽管在所有的检查列上都有索引，但某些形式的WHERE子句强迫优化器使用顺序存取.
4， 避免相关子查询
         一个 列 的 标签同时在主查询和WHERE子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次.查询嵌套层次越多，效率越低，因此应当尽量避免子查询.
5， 避免困难的正规表达式
        MA TC HE S和UKE关键字支持通配符匹配，技术上叫正规表达式，但这种匹配特别耗费时间，例如下列语句.
SE LE C T * F R OM studentWHEREnumberLIKE "0404_ _ _" 即使 在 nu mber字段上建立了索引，在这种情况下也还是采用顺序扫描的方式，如果把语句改为下列语句：SE LE C T * FR O M studentWHEREnumber>"0404444"，上述 语 句 在执行查询时就会利用索引来查询，显然会大大提高速度.
6， 使用临时表加速查询
         把表 的 一 个子集进行排序并创建临时表，有时能加速查询.它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作.临时表创建后不会反映主表的修改，在主表中数据频繁修改的情况下，注意不要丢失数据

7， 优化WHERE子句
          WH ER E 子句中对列的任何操作结果都是在SQL运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引。如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优化，使用索引以避免表搜索.
8， 分解查询
          这种 方 法 是把查询分解执行，根据付出开销的多少来决定如何分解，如何执行.一元子查询提取几乎总会得到好处，因为在关系运算之前尽可能减少关系的体积对减少相应的系统开销起很大的作用，通常会得到期待的优化结果，但也并不是绝对如此