SQL Server SQL语句调优技巧综合教程.docx

SQLServerSQL语句调优技巧综合教程SQLServerSQL语句调优技巧综合教程（精选3篇），下面是小编给大家带来的SQLServerSQL语句调优技巧综合教程，以供大家参考，我们一起来看看吧!篇1：SQLServerSQL语句调优技巧综合教程通过例子和解析计划，本文展示了在MicrosoftSQLServer上提高查询效率有效的一些技巧，在编程中有很多小提示和技巧。了解这些技巧可以扩展你在性能优化上的可用机能。在这部分里我们所有的例子都选择使用MicrosoftSHOWPLAN_ALL输出，因为它更紧凑并且展示典型的信息。（Sybase的查询计划基本与此相同，可能包含其它一些信息）大部分的例子都是要么基于PUBS数据库，要么基于标准系统表的。我们在PUBS数据库中对用到的表进行了很大扩充，对很多表增加了好几万行。子查询优化一条好的值得称赞的规则是尽量用连接代替所有的子查询。优化器有时可以自动将子查询“扁平化”，并且用常规或外连接代替。但那样也不总是有效。明确的连接对选择表的顺序和找到最可能的计划给出了更多的选项。当你优化一个特殊查询时，了解一下是否去掉自查询可产生很大的差异。示例下面查询选择了pubs数据库中所有表的名字，以及每个表的聚集索引（如果存在）。如果没有聚集索引，表名仍然显示在列表中，在聚集索引列中显示为虚线。两个查询返回同样的结果集，但第一个使用了一个子查询，而第二个使用一个外连接时。比较MicrosoftSQLServer产生的查询计划：不必更深探索，我们可以看到在CPU和总的实耗时间方面连接更快，仅需要子查询方案逻辑读的一半。此外，这两种情况伴随着相同的结果集，虽然排序的顺序不同，这是因为连接查询（由于它的GROUPBY子句）有一个隐含的ORDERBY：查看这个子查询方法展示的查询计划：反之，求和查询操作我们可以得到：使用连接是更有效的方案。它不需要额外的流聚合（streamaggregate），即子查询所需在big_sales.qty列的求和。UNIONvsUNIONALL无论何时尽可能用UNIONALL代替UNION。其中的差异是因为UNION有排除重复行并且对结果进行排序的副作用，而UNIONALL不会做这些工作。选择无重复行的结果需要建立临时工作表，用它排序所有行并且在输出之前排序。（在一个selectdistinct查询中显示查询计划将发现存在一个流聚合，消耗百分之三十多的资源处理查询）。当你确切知道你得需要时，可以使用UNION。但如果你估计在结果集中没有重复的行，就使用UNIONALL吧。它只是从一个表或一个连接中选择，然后从另一个表中选择，附加在第一条结果集的底部。UNIONALL不需要工作表和排序（除非其它条件引起的）。在大部分情况下UNIONALL更具效率。一个有潜在危险的问题是使用UNION会在数据库中产生巨大的泛滥的临时工作表。如果你期望从UNION查询中获得大量的结果集时，这就可能发生。示例下面的查询是选择pubs数据库中的表sales的所有商店的ID，也选择表big_sales中的所有商店的ID，这个表中我们加入了70，000多行数据。在这两个方案间不同之处仅仅是UNION与UNIONALL的使用比较。但在这个计划中加入ALL关键字产生了三大不同。第一个方案中，在返回结果集给客户端之前需要流聚合并且排序结果。第二个查询更有效率，特别是对大表。在这个例子中两个查询返回同样的结果集，虽然顺序不同。在我们的测试中有两个临时表。你的结果可能会关键字：SQLServer篇2：教你轻松学会SQLServer记录轮班的技巧综合教程例：公司员工采取三个轮班制度：凌晨0：00到早上8：00为第一班，早上8：00到下午4：00为第二班，下午4：00到晚上12：00为第三班，员工使用电子时钟进行签名，这种电子签名可以自动将记录添加到SQLServer数据库中。但是，有时候，需要增加一个夜班；即使这个轮班发生在第二天，它仍然会被认为是第三班。你也许希望根据轮班对记录进行分组，但是在你的计划中会有两个非常令人头痛的问题：(1）不是所有的雇员都是按时到达的；(2）有时候员工工作的时间会比他们的一个轮班的时间长一些。为了能在你的列表中得到正确的分组，你必须假设所有的员工能在一个轮班的开始和结束时间之间的任意时间开始工作。使用CASE语句是一种解决办法。ListingA中的SQL语句告诉我们，在创建测试表没有错误的情况下，它是如何工作的。为了使程序代码完全准确的运行，你需要在时间的小窗口中得到每一个轮班的开始时间和下一个轮班的结束时间。在刚才的例子中，你可以用'15:59:59.123'这个值代替@StartTime，然后再重新运行代码。这时候，你必须在每一个轮班结束的分界点上增加999毫秒。解决方案这个