SQL Server SQL语句调优技巧(1)
来源:互联网 发布:经典英文歌知乎 编辑:程序博客网 时间:2024/06/02 05:02
在这部分里我们所有的例子都选择使用Microsoft SHOWPLAN_ALL输出,因为它更紧凑并且展示典型的信息。(Sybase的查询计划基本与此相同,可能包含其它一些信息)大部分的例子都是要么基于PUBS数据库,要么基于标准系统表的。我们在PUBS数据库中对用到的表进行了很大扩充,对很多表增加了好几万行。
子查询优化 一条好的值得称赞的规则是尽量用连接代替所有的子查询。优化器有时可以自动将子查询“扁平化”,并且用常规或外连接代替。但那样也不总是有效。明确的连接对选择表的顺序和找到最可能的计划给出了更多的选项。当你优化一个特殊查询时,了解一下是否去掉自查询可产生很大的差异。 示例 下面查询选择了pubs数据库中所有表的名字,以及每个表的聚集索引(如果存在)。如果没有聚集索引,表名仍然显示在列表中,在聚集索引列中显示为虚线。两个查询返回同样的结果集,但第一个使用了一个子查询,而第二个使用一个外连接时。比较Microsoft SQL Server产生的查询计划: 不必更深探索,我们可以看到在CPU和总的实耗时间方面连接更快,仅需要子查询方案逻辑读的一半。此外,这两种情况伴随着相同的结果集,虽然排序的顺序不同,这是因为连接查询(由于它的GROUP BY子句)有一个隐含的ORDER BY: 查看这个子查询方法展示的查询计划: 反之,求和查询操作我们可以得到: 使用连接是更有效的方案。它不需要额外的流聚合(stream aggregate),即子查询所需在big_sales.qty列的求和。 UNION vs UNION ALL 无论何时尽可能用UNION ALL 代替UNION。其中的差异是因为UNION有排除重复行并且对结果进行排序的副作用,而UNION ALL不会做这些工作。选择无重复行的结果需要建立临时工作表,用它排序所有行并且在输出之前排序。(在一个select distinct 查询中显示查询计划将发现存在一个流聚合,消耗百分之三十多的资源处理查询)。当你确切知道你得需要时,可以使用UNION。但如果你估计在结果集中没有重复的行,就使用UNION ALL吧。它只是从一个表或一个连接中选择,然后从另一个表中选择,附加在第一条结果集的底部。UNION ALL不需要工作表和排序(除非其它条件引起的)。在大部分情况下UNION ALL更具效率。一个有潜在危险的问题是使用UNION会在数据库中产生巨大的泛滥的临时工作表。如果你期望从UNION查询中获得大量的结果集时,这就可能发生。 示例 下面的查询是选择pubs数据库中的表sales的所有商店的ID,也选择表big_sales中的所有商店的ID,这个表中我们加入了70,000多行数据。在这两个方案间不同之处仅仅是UNION 与UNION ALL的使用比较。但在这个计划中加入ALL关键字产生了三大不同。第一个方案中,在返回结果集给客户端之前需要流聚合并且排序结果。第二个查询更有效率,特别是对大表。在这个例子中两个查询返回同样的结果集,虽然顺序不同。在我们的测试中有两个临时表。你的结果可能会稍有差异。 虽然在这个例子的结果集是可互换的,你可以看到UNION ALL语句比UNION语句少消耗一半的资源。所以应当预料你的结果集并且确定已经没有重复时,使用UNION ALL子句。<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 728x15, 创建于 08-4-23MSDN */google_ad_slot = "3624277373";google_ad_width = 728;google_ad_height = 15;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>