SQL 查询优化

SQL优化----百万数据查询优化
百万数据查询优化
1．合理使用索引

　　索引是数据库中重要的数据结构，它的根本目的就是为了提升查询效率。如今大多数的数据库产品都采用IBM最早提出的ISAM索引结构。索引的使用要恰到好处，其使用原则以下：

　　●在常常进行链接，可是没有指定为外键的列上创建索引，而不常常链接的字段则由优化器自动生成索引。

　　●在频繁进行排序或分组（即进行group by或order by操做）的列上创建索引。

　　●在条件表达式中常常用到的不一样值较多的列上创建检索，在不一样值少的列上不要创建索引。好比在雇员表的“性别”列上只有“男”与“女”两个不一样值，所以就无必要创建索引。若是创建索引不但不会提升查询效率，反而会严重下降更新速度。

　　●若是待排序的列有多个，能够在这些列上创建复合索引（compound index）。

　　●使用系统工具。如Informix数据库有一个tbcheck工具，能够在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者由于频繁操做而使得读取效率下降，若是一个使用索引的查询不明不白地慢下来，能够试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引能够提升查询速度。

　　2．避免或简化排序

　　应当简化或避免对大型表进行重复的排序。当可以利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。如下是一些影响因素：

　　●索引中不包括一个或几个待排序的列；

　　●group by或order by子句中列的次序与索引的次序不同；

　　●排序的列来自不一样的表。

　　为了不没必要要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提升是值得的）。若是排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。

　　3．消除对大型表行数据的顺序存取

　　在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。好比采用顺序存取策略，一个嵌套3层的查询，若是每层都查询1000行，那么这个查询就要查询10亿行数据。 A）避免这种状况的主要方法就是对链接的列进行索引。

　　B) 还可使用并集来避免顺序存取（将or改为union）。尽管在全部的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操做：

　　SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008

　　虽然在customer_num和order_num上建有索引，可是在上面的语句中优化器仍是使用顺序存取路径扫描整个表。由于这个语句要检索的是分离的行的集合，因此应该改成以下语句：

　　SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001

　　UNION

　　SELECT ＊ FROM orders WHERE order_num=1008

　　这样就能利用索引路径处理查询。

4．避免相关子查询

　　一个列的标签同时在主查询和where子句中的查询中出现，那么极可能当主查询中的列值改变以后，子查询必须从新查询一次。查询嵌套层次越多，效率越低，所以应当尽可能避免子查询。若是子查询不可避免，那么要在子查询中过滤掉尽量多的行。

　　5．避免困难的正规表达式

　　MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”

　　即便在zipcode字段上创建了索引，在这种状况下也仍是采用顺序扫描的方式。若是把语句改成SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提升速度。

　　另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3] >“80”，在where子句中采用了非开始子串，于是这个语句也不会使用索引。

　　6．使用临时表加速查询

　　把表的一个子集进行排序并建立临时表，有时能加速查询。有助于避免多重排序操做，并且在其余方面还能简化优化器的工做。例如：

　　SELECT cust.name，rcvbles.balance，……other columns

　　FROM cust，rcvbles

　　WHERE cust.customer_id = rcvlbes.customer_id

　　AND rcvblls.balance>0

　　AND cust.postcode>“98000”

　　ORDER BY cust.name

　　若是这个查询要被执行屡次而不止一次，能够把全部未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：

　　SELECT cust.name，rcvbles.balance，……other columns

　　FROM cust，rcvbles

　　WHERE cust.customer_id = rcvlbes.customer_id

　　AND rcvblls.balance>0

　　ORDER BY cust.name

　　INTO TEMP cust_with_balance

　　而后如下面的方式在临时表中查询：

　　SELECT ＊ FROM cust_with_balance

　　WHERE postcode>“98000”

　　临时表中的行要比主表中的行少，并且物理顺序就是所要求的顺序，减小了磁盘I/O，因此查询工做量能够获得大幅减小。

　　注意：临时表建立后不会反映主表的修改。在主表中数据频繁修改的状况下，注意不要丢失数据。

　

　　小　结

　　20％的代码用去了80％的时间，这是程序设计中的一个着名定律，在数据库应用程序中也一样如此。咱们的优化要抓住关键问题，对于数据库应用程序来讲，重点在于SQL的执行效率。查询优化的重点环节是使得数据库服务器少从磁盘中读数据以及顺序读页而不是非顺序读页。

第二部分（如何让引擎充分使用索引）
l 百万数据查询优化技巧三十则

1.创建索引 对查询进行优化，应尽可能避免全表扫描，首先应考虑在 where 及 order by 涉及的列上创建索引。

2.应尽可能避免在 where 子句中对字段进行 null 值判断，不然将致使引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

能够在num上设置默认值0，确保表中num列没有null值，而后这样查询：

select id from t where num=0

3.应尽可能避免在 where 子句中使用!=或<>操做符，不然将引擎放弃使用索引而进行全表扫描。

4.应尽可能避免在 where 子句中使用 or 来链接条件，可以使用union，不然将致使引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or num=20

能够这样查询：

select id from t where num=10

union all

select id from t where num=20

5.in 和 not in 也要慎用，不然会致使全表扫描，如：

select id from t where num in(1,2,3)

对于连续的数值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

6.下面模糊查询也将致使全表扫描：

select id from t where name like '%abc%'

若要提升效率，能够考虑全文检索。

7.若是在 where 子句中使用参数，也会致使全表扫描。

由于SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，若是在编译时创建访问计划，变量的值仍是未知的，于是没法做为索引选择的输入项。以下面语句将进行全表扫描：

select id from t where num=@num

能够改成强制查询使用索引：

select id from t with(index(索引名)) where num=@num

8.应尽可能避免在 where 子句中对字段进行表达式操做，这将致使引擎放弃使用索引而进行全表扫描。如：

select id from t where num/2=100

应改成:

select id from t where num=100*2

9.应尽可能避免在where子句中对字段进行函数（内置函数）操做，

这将致使引擎放弃使用索引而进行全表扫描。如：

select id from t where substring(name,1,3)='abc'--name以abc开头的id

select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id

应改成:

select id from t where name like 'abc%'

select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

10.不要在 where 子句中的“=”左边进行函数、算术运算或其余表达式运算，不然系统将可能没法正确使用索引。

11.在使用索引字段做为条件时，若是该索引是复合索引，那么必须使用到该索引中的第一个字段做为条件时才能保证系统使用该索引，不然该索引将不会被使用，而且应尽量的让字段顺序与索引顺序相一致。

12.不要写一些没有意义的查询，如须要生成一个空表结构：

select col1,col2 into #t from t where 1=0

这类代码不会返回任何结果集，可是会消耗系统资源的，应改为这样：

create table #t(...)

13.不少时候用 exists 代替 in 是一个好的选择（缘由：请参考个人博客）：

select num from a where num in(select num from b)

用下面的语句替换：

select num from a where exists(select 1 from b where num=a.num)

14.并非全部索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引（除非是位图索引），如一表中有字段sex，male、female几乎各一半，那么即便在sex上建了索引也对查询效率起不了做用。

15.索引并非越多越好，索引当然能够提升相应的 select 的效率，但同时也下降了 insert 及 update 的效率，由于 insert 或 update 时有可能会重建索引，因此怎样建索引须要慎重考虑，视具体状况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

16.应尽量的避免更新 clustered 索引数据列，由于 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将致使整个表记录的顺序的调整，会耗费至关大的资源。若应用系统须要频繁更新 clustered 索引数据列，那么须要考虑是否应将该索引建为 clustered 索引。

17.尽可能使用数字型字段，若只含数值信息的字段尽可能不要设计为字符型，这会下降查询和链接的性能，并会增长存储开销。这是由于引擎在处理查询和链接时会逐个比较字符串中每个字符，而对于数字型而言只须要比较一次就够了。

18.尽量的使用 varchar/nvarchar 代替 char/nchar，最好用varchar2（自变长度） ，由于首先变长字段存储空间小，能够节省存储空间，其次对于查询来讲，在一个相对较小的字段内搜索效率显然要高些。

19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。

20.尽可能使用表变量来代替临时表（通常用在存储过程当中）。若是表变量包含大量数据，请注意索引很是有限（只有主键索引）。

21.避免频繁建立和删除临时表，以减小系统表资源的消耗。

22.临时表并非不可以使用，适当地使用它们可使某些例程更有效，例如，当须要重复引用大型表或经常使用表中的某个数据集时。可是，对于一次性事件，最好使用导出表。

23.在新建临时表时，若是一次性插入数据量很大，那么可使用 select into A select。。。 代替 create table，避免形成大量 log ，以提升速度；若是数据量不大，为了缓和系统表的资源，应先create table，而后insert。

24.若是使用到了临时表，在存储过程的最后务必将全部的临时表显式删除，先 truncate table ，而后 drop table ，这样能够避免系统表的较长时间锁定。

25.尽可能避免使用游标，由于游标的效率较差，若是游标操做的数据超过1万行，那么就应该考虑改写。

26.使用基于游标的方法或临时表方法以前，应先寻找基于集的解决方案来解决问题，基于集的方法一般更有效。

27.与临时表同样，游标并非不可以使用。对小型数据集使用 FAST_FORWARD 游标一般要优于其余逐行处理方法，尤为是在必须引用几个表才能得到所需的数据时。在结果集中包括“合计”的例程一般要比使用游标执行的速度快。若是开发时间容许，基于游标的方法和基于集的方法均可以尝试一下，看哪种方法的效果更好。

28.在全部的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每一个语句后向客户端发送 DONE_IN_PROC 消息。

29.尽可能避免大事务操做，提升系统并发能力。

30.尽可能避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。