本文介绍了通过合理建立索引、避免或简化排序、使用连接等多种方式提高SQL查询效率的方法。合理利用索引能显著提升数据库性能。
数据库系统是管理信息系统的核心，基于数据库的联机事务处理(OLTP)和联机分析处理(OLAP)是各使用单位最为重要的计算机应用之一。从大多数系统的应用实例来看，查询、分析、统计是系统的最终应用，而查询、分析、统计等操作所基于的SELECT语句在SQL语句中又是付出资源代价最大的语句。所以对它进行优化将有利于提高数据库的查询效率。
合理建立索引提高查询效率
索引是数据库中重要的数据结构，它的用途就是为了提高查询效率。采用索引来加快数据处理速度也成为广大数据库用户一致接受的优化方法。索引的使用要恰到好处，其使用原则如下：
1.在经常进行连接，但是没有指定为外键的列上建立索引。
2.在频繁进行排序或分组(即进行group by或order by操作)的列上建立索引。
3.在条件表达式中经常用到的不同值较多的列上建立索引，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就没有必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
4.如果待排序的列有多个，可以在这些列上建立复合索引(compound index)。
5.不能用null作索引，任何包含null值的列都将不会被包含在索引中。也就是说如果某列存在空值，即使对该列建索引也不会提高查询效率。
6.对查询型的表，建立多个索引会大大提高查询速度，对更新型的表，如果索引过多，会增大开销。
在实际应用中可以使用系统工具帮助我们分析建立索引。如MS SQL Server的查询分析器。
避免或简化排序(order by操作)
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
1.索引中不包括一个或几个待排序的列；
2.group by或order by子句中列的次序与索引的次序不一样；
3.排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表(尽管有时可能影响表的规范化，但相对于效率的提高是值得的)。如果排序不可避免，那么应当试图简化它，如缩小要排序的列的范围等。
使用连接，避免对数据表的顺序存取
在嵌套查询中，对表的顺序存取可能会对查询效率产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如两个表：学生表(学号、姓名、年龄……)和选课表(学号、课程号、成绩)。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的Where子句强迫优化器使用顺序存取。下面的查询将强迫对table1表执行顺序操作：
SELECT * FROM table1 WHERE (user_num=104 AND user_id＞1001) OR user_id =1008
虽然在user_num和user_id上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：
SELECT * FROM table1 WHERE us er_num =104 AND user_id＞1001
UNION
SELECT * FROM table1 WHERE us er_id=1008
这样就能利用索引路径处理查询。
避免困难的正规表达式
某些关键字的应用是正确的，技术上叫正规表达式，但有时搭配不当会非常耗费时间，特别是在大型数据表中体现得尤为突出，我们把这种正规表达式称为困难的正规表达式。
在实际应用中避免这种困难的正规表达式的方法有以下几条：
1.支持通配符的CHARINDEX和LIKE关键字
举例来讲：
SELECT * FROM table1 WHERE us er_id LIKE “98_ _ _”
即使在user_id字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT * FROM table1 WHERE user_id ＞“98000”
在执行查询时就会利用索引来查询，显然会大大提高速度。
比如查找用户名包含有“c”的所有用户，可以用
SELECT * FROM table1 WHERE us er_name LIKE “%c%”
下面是完成上面功能的另一种写法：
SELECT * FROM table1 WHERE CHARINDEX (“c”user_name)＞0
这种方法理论上比上一种方法多了一个判断语句，即＞0， 但这个判断过程是最快的。通常80%以上的运算都是花在查找字符串及其他的运算上。 用这种方法也有好处， 那就是对“%”、“|”等在不能直接用LIKE 查找到的字符中可以直接在这CHARINDEX中运用。如下所示：
SELECT * FROM table1 WHERE CHARINDEX (“%”,user_name)＞0
2.少使用“*”
比如如下语句：
SELECT COUNT (*) FROM table1
这时用“*”和一个实际的列名得到的都是一个行数的结果，但是用“*”会统计所有列，显然要比用一个实际的列名效率低。同样，尽管很多开发人员都习惯采用“SELECT * FROM TBL”的模式进行查询，但是为了提高系统的效率，如果你只需要其中某几个字段值的话，最好把这几个字段直接写出来。
3.尽量不要在WHERE子句中对字段使用函数或参与表达式来计算
这样会导致无法使用索引进行全表扫描。
4.尽量少使用NOT
5.IN和EXISTS
EXISTS要远比IN的效率高，里面关系到full table scan和range scan。同时应尽可能使用NOT EXISTS来代替NOT IN，尽管二者都使用了NOT(不能使用索引而降低速度)，但是NOT EXISTS要比NOT IN查询效率更高。
6.慎用游标
在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，这样可使性能得到明显提高。
7.在海量查询时尽量少用格式转换
8.IN、OR子句常会使工作表的索引失效
如果不产生大量重复值，可以考虑把子句拆开，拆开的子句中应该包含索引。
小 结
其实SQL的查询性能优化是一个复杂的过程，上述这些只是在应用层面的一种体现，此外，还有采用临时表等技术未涉及。而它优化的实质就是在结果正确的前提下，充分利用索引，减少表扫描的I/O次数，尽量避免全表搜索的发生。
合理建立索引提高查询效率
索引是数据库中重要的数据结构，它的用途就是为了提高查询效率。采用索引来加快数据处理速度也成为广大数据库用户一致接受的优化方法。索引的使用要恰到好处，其使用原则如下：
1.在经常进行连接，但是没有指定为外键的列上建立索引。
2.在频繁进行排序或分组(即进行group by或order by操作)的列上建立索引。
3.在条件表达式中经常用到的不同值较多的列上建立索引，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就没有必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
4.如果待排序的列有多个，可以在这些列上建立复合索引(compound index)。
5.不能用null作索引，任何包含null值的列都将不会被包含在索引中。也就是说如果某列存在空值，即使对该列建索引也不会提高查询效率。
6.对查询型的表，建立多个索引会大大提高查询速度，对更新型的表，如果索引过多，会增大开销。
在实际应用中可以使用系统工具帮助我们分析建立索引。如MS SQL Server的查询分析器。
避免或简化排序(order by操作)
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
1.索引中不包括一个或几个待排序的列；
2.group by或order by子句中列的次序与索引的次序不一样；
3.排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表(尽管有时可能影响表的规范化，但相对于效率的提高是值得的)。如果排序不可避免，那么应当试图简化它，如缩小要排序的列的范围等。
使用连接，避免对数据表的顺序存取
在嵌套查询中，对表的顺序存取可能会对查询效率产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如两个表：学生表(学号、姓名、年龄……)和选课表(学号、课程号、成绩)。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的Where子句强迫优化器使用顺序存取。下面的查询将强迫对table1表执行顺序操作：
SELECT * FROM table1 WHERE (user_num=104 AND user_id＞1001) OR user_id =1008
虽然在user_num和user_id上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：
SELECT * FROM table1 WHERE us er_num =104 AND user_id＞1001
UNION
SELECT * FROM table1 WHERE us er_id=1008
这样就能利用索引路径处理查询。
避免困难的正规表达式
某些关键字的应用是正确的，技术上叫正规表达式，但有时搭配不当会非常耗费时间，特别是在大型数据表中体现得尤为突出，我们把这种正规表达式称为困难的正规表达式。
在实际应用中避免这种困难的正规表达式的方法有以下几条：
1.支持通配符的CHARINDEX和LIKE关键字
举例来讲：
SELECT * FROM table1 WHERE us er_id LIKE “98_ _ _”
即使在user_id字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT * FROM table1 WHERE user_id ＞“98000”
在执行查询时就会利用索引来查询，显然会大大提高速度。
比如查找用户名包含有“c”的所有用户，可以用
SELECT * FROM table1 WHERE us er_name LIKE “%c%”
下面是完成上面功能的另一种写法：
SELECT * FROM table1 WHERE CHARINDEX (“c”user_name)＞0
这种方法理论上比上一种方法多了一个判断语句，即＞0， 但这个判断过程是最快的。通常80%以上的运算都是花在查找字符串及其他的运算上。 用这种方法也有好处， 那就是对“%”、“|”等在不能直接用LIKE 查找到的字符中可以直接在这CHARINDEX中运用。如下所示：
SELECT * FROM table1 WHERE CHARINDEX (“%”,user_name)＞0
2.少使用“*”
比如如下语句：
SELECT COUNT (*) FROM table1
这时用“*”和一个实际的列名得到的都是一个行数的结果，但是用“*”会统计所有列，显然要比用一个实际的列名效率低。同样，尽管很多开发人员都习惯采用“SELECT * FROM TBL”的模式进行查询，但是为了提高系统的效率，如果你只需要其中某几个字段值的话，最好把这几个字段直接写出来。
3.尽量不要在WHERE子句中对字段使用函数或参与表达式来计算
这样会导致无法使用索引进行全表扫描。
4.尽量少使用NOT
5.IN和EXISTS
EXISTS要远比IN的效率高，里面关系到full table scan和range scan。同时应尽可能使用NOT EXISTS来代替NOT IN，尽管二者都使用了NOT(不能使用索引而降低速度)，但是NOT EXISTS要比NOT IN查询效率更高。
6.慎用游标
在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，这样可使性能得到明显提高。
7.在海量查询时尽量少用格式转换
8.IN、OR子句常会使工作表的索引失效
如果不产生大量重复值，可以考虑把子句拆开，拆开的子句中应该包含索引。
小 结
其实SQL的查询性能优化是一个复杂的过程，上述这些只是在应用层面的一种体现，此外，还有采用临时表等技术未涉及。而它优化的实质就是在结果正确的前提下，充分利用索引，减少表扫描的I/O次数，尽量避免全表搜索的发生。
扫一扫
366
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
