SQL语句执行计划分析

《SQL语句执行计划分析》由会员分享，可在线阅读，更多相关《SQL语句执行计划分析（12页珍藏版）》请在金锄头文库上搜索。

1、 Table Scan（表扫描）：如果看到这个信息，就说明数据表上没有聚集索引，或者查 询优化器没有使用索引来查找。意即资料表的每一行都被检查到。如果资料表相对较小的话， 表扫描可以非常快速,有时甚至快过使用索引。因此,当看到有执行表扫描时 ,第一件要做的事就是看看数据表有多少数据行 .如果不是太多的 话，那么表扫描可能提供了最好的总体效能。但如果数据表大的话,表扫描就极可能需要长时间 来完成，查询效能就大受影响。在这种情况下，就需要仔细研究，为数据表增加一个适当的索 引用于这个查询。假设你发现某查询使用了表扫描，有一个合适的非聚集索引，但它没有用到。这意味着什么呢？ 为什么这个索引没有用到呢

2、？如果需要获得的数据量相对数据表大小来说非常大，或者数据选 择性不高（意味着同一个字段中重复的值很多）,表扫描经常会比索引扫描快。例如，如果一个 数据表有10 0 00个数据行，查询返回1 0 0 0行，如果这个表没有聚集索引的话，那么表扫描将比 使用一个非聚集索引更快。或者如果数据表有100 0 O个数据行，且同一个字段（WHERE条件 句有用到这个字段）上有1000笔重复的数据，表扫描也会比使用非聚集索引更快。查看图形执行计划上的数据表上的弹出式窗口时，请注意”预估的资料行数（Esti mated Row Count）”.这个数字是查询优化器作出的多少个数据行会被返回的最佳推测。如果执行了

3、表扫描 且”预估的数据行数”数值很高的话，就意味着返回的记录数很多，查询优化器认为执行表扫描比 使用可用的非聚集索引更快。 index Seek（索引査找）：索引查找意味着查询优化器使用了数据表上的非聚集索引来 查找数据.性能通常会很快，尤其是当只有少数的数据行被返回时。 Clustered Index Seek（聚集索引査找）:这指查询优化器使用了数据表上的聚集索引 来查找数据，性能很快。实际上，这是SQL Ser ve r能做的最快的索引查找类型。 Clustered Index Scan （聚集索引扫描）：聚集索引扫描与表扫描相似，不同的是聚 集索引扫描是在一个建有聚集索引的数据表上执行

4、的。和一般的表扫描一样，聚集索引扫描可 能表明存在效能问题。一般来说，有两种原因会引此聚集索引扫描的执行.第一个原因，相对于 数据表上的整体数据行数目，可能需要获取太多的数据行。查看”预估的数据行数量（Estima ted Row Count） ”可以对此加以验证。第二个原因，可能是由于WHERE条件句中用到的字 段选择性不高.在任何情况下，与标准的表扫描不同，聚集索引扫描并不会总是去查找数据表中 的所有数据，所以聚集索引扫描一般都会比标准的表扫描要快。通常来说，要将聚集索引扫描 改成聚集索引查找，你唯一能做的是重写查询语句，让语句限制性更多，从而返回更少的数据 行。绝大多数情况下，查询优化器

5、会对连接进行分析，按最有效率的顺序 ,使用最有效率的连接类型来对数据 表进行连接.但并不总是如此.在图形执行计划中你可以看到代表查询所使用到的各种不同连接类型的图 标。此外，每个连接图标都有两个箭头指向它。指向连接图标的上面的箭头代表该连接的外部表,下面的箭 头则代表这个连接的内部表。箭头的另一头则指向被连接的数据表名.有时在多表连接的查询中，箭头的另一头指向的并不是一个数据表，而是另一个连接。如果将鼠标移到指 向外部连接与内部连接的箭头上,就可以看到一个弹出式窗口,告诉你有多少数据行被发送至这个连接来进 行处理.外部表应该总是比内部表含有更少的数据行。如果不是，则说明查询优化器所选择的连接顺

6、序可能 不正确(下面是关于这个话题的更多信息).首先，让我们来看看连接类型。SQL Server可以使用三种不同的技术来连接资料表:嵌套循环(neste d loop),散列(hash)，以及合并(me rge)。一般来说,嵌套循环是最快的连接类型，但如果不可能使用 嵌套循环的话,则会用到散列或者合并作为合适的连接类型。两者都比嵌套循环连接慢。当连接大表时，则合并连接可能是最佳选项，而非嵌套循环连接。唯一的明确这一点的方式是对两者都进 行测试以查看哪一个最有效率。如果你怀疑某个查询速度慢的原因可能是因为它所使用的连接类型不理想，那么你可以使用连接提示来复 盖查询优化器的选择。在使用连接提示之前

7、,你需要花费一些时间去了解一下每种连接类型以及它们的工作 方式。这是一个复杂的话题，超出了本文的讨论范围.查询优化器选择最有效率的连接类型来连接数据表.例如，嵌套循环连接的外部表应该是连接的两个表中较 小的那个表。散列连接也是一样，它的外部表应该是较小的那个表.如果你觉得查询优化器选择的连接顺序 是错误的,可以使用连接提示来复盖它。很多情况下，唯一的确认使用连接提示改变连接类型或连接顺序是提升还是降低了效能的方式，就是对它们进行测试，看看发生了什么.7. 0, 200 0 , 2 005如果你的SQL Ser ve r有多个CPU,并且没有修改SQL Ser ve r的默认设置来限制SQL S

8、erver 使用服务器上所有CPU的能力，那么查询优化器会考虑使用平行处理(paral lei ism)来执行某些査 询平行处理指在多个CPU上同时运行一个查询的能力。很多情况下，一个运行在多个处理器上的查询比 仅运行在单个处理器上的査询要快,但并不总是这样。查询优化器并不会总是使用平行处理,即使在它能使用的时候。这是因为查询优化器在决定使用平行处理前 会考虑到各种不同的因素例如当前SQL Server上处于活动状态的连接数量，CPU忙碌程度，是否有足 够的内存来运行平行化查询，需要处理的数据行数量，以及这个查询的类型.查询优化器收集到这些真实的 数据后,再决定平行处理是不是运行这个查询的最佳

9、选择。你可能会发现,某次一个查询没有用到平行处理, 但稍后某次再次运行同样的查询时,却又用到了平行处理。有时,使用多个处理器所需的花费会大于使用它们能所能节省的资源尽管查询处理器的确会衡量使用平行 查询的正反两面的影响,但它的猜想并不总是正确的。如果怀疑平行处理防碍了某条查询的性能，你可以使用OPTION (MAXDOP 1)提示来关闭该查询的平 行处理。决定是否使用平行处理的唯一方式是通过这两种方式对查询进行测试，看看发生了什么。7。0, 2000, 20 0 5* 查看图形执行计划时，你可能会发现某个图标的文字用红色显示,而非通常情况下的黑色。这意味着相关的 表的一些统计数据遗失，统计数据

10、是查询优化器生成一个好的执行计划所必须的。遗失的统计数据可以通过右键这个图标，并选择”创建遗失的统计资料”来创建.这时会弹出”创建遗失的统 计数据”对话框,通过它可以很容易地创建遗失的统计数据.当可以选择去更新遗失的统计资料时,应该总是这样做,因为这样极有可能让你正在分析的查询语句从中获 得效能上的好处。7。0,2000,20 0 5*有时你会在图形执行计划上看到标识了 ”Asse rt”的图标这意味着查询优化器正在验证查询语句是否 有违反引用完整性或者条件约束。如果没有,则没有问题。但如果有的话,查询优化器将无法为该查询建 立执行计划，同时会产生一个错误。7. 0, 200 0 , 20 0

11、 5 *你常常会在图形执行计划上看到标识成书签查找(Bookmark Lookup) ”的图标。书签查找相当常 见.书签查找的本质是告诉你查询处理器必须从数据表或者聚集索引中来查找它所需要的数据行,而不是从 非聚集索引中直接读取。打比方说，如果一个查询语句的SELECTJOIN以及WHERE子句中的所有字段，都不存在于那个用来 定位符合查询条件的数据行的非聚集索引中,那么查询优化器就不得不做额外的工作在数据表或聚集索引 中查找那些满足这个查询语句的字段。另一种引起书签查找的原因是使用了 SELECT*。由于在绝大多情况下它会返回比你实际所需更多的数 据，所以应该永不使用SELECT水.从性能方

12、面来说，书签查找是不理想的。因为它会请求额外的I/O开销在字段中查找以返回所需的数据行. 如果认为书签查找防碍了查询的性能，那么有四种选择可以用来避免它：可以建立WH ERE子句会用到的 聚集索引，利用索引交集的优势，建立覆盖的非聚集索引，或者(如果是SQL Serve r 2 0 00/2005企业 版的话)可以建立索引视图。如果这些都不可能，或者使用它们中的任何一个都会耗用比书签查找更多的资 源，那么书签查找就是最佳的选择了.7。 0， 2000， 2005有时査询优化器需要在tempdb数据库中建立临时工作表.如果是这样的话，就意味着图形执行计划中 有标识成 I ndex Spo ol，

13、 Row Count Spool 或者 Tab le Spool 的图标。任何时候，使用到工作表一般都会防碍到性能，因为需要额外的 I/O 开销来维护这个工作表.理想情况下 应该不要用到工作表.不幸的是并不能总是避免用到工作表。有时当使用工作表比其它选择更有效率时，它 的使用实际上会增强性能。不论何种情况，图形执行计划中的工作表都应该引起你的警觉。应该仔细检查这样的查询语句，看看是否有 办法重写查询来避免用到工作表。有可能没有办法.但如果有的话，你就朝提升这个查询的性能方面前进了 一步.7。0，2 000，2005.在图形执行计划上看到流聚合(Stream Aggregate)图标就意味着有对

14、一个单一的输入进行了聚 合。当使用了DISTINCT子句，或者任何聚合函数时，如AVG, COUNT, MAX, MIN,或者SU M等，流聚合操作就相当常见.7.0, 20 0 0, 2005*查询分析器与Management Stu di o不是唯一的可以生成、显示査询执行计划的工具.SQL Serv er Pr of ile r也可以显示执行计划，但格式是文本形式的。使用SQL Server Pr ofi 1 e r来显示执 行计划的一个优势是，它能为实际运行的大量查询产生执行计划。如果使用查询分析器和m anagement Studi o,则一次只能运行一个.使用Pr ofiler捕获

15、、显示执行计划时，必须使用如下的配置生成一个追踪：捕获事件 Perf or ma nee: Execution P la n Perf or man c e: Show Pla n All Performan c e: S how Plan Statistic s Performance: Show Plan Text显示的字段 StartTime Du rat ion Tex tData CPU Reads Writes过滤条件 Du ration.你会想指定最大的查询执行时间，例如5秒钟，由此避免得到太大量的数据。当然,你可以在你的追踪中捕获更多的没有例在上面的信息，上面例出的只是一个指南

16、而已.但必须记住不 要去捕获太多的数据，否则，追踪的运行会影响服务器的性能。7。0,2000, 2 005*如果在査询中使用了 OPTION FAST提示，那就必须小心执行计划的结果可能不是你所期望的。这时 你所看到的执行计划基于使用了 FAST提示的结果，而不是整个查询语句的实际执行计划。FAST提示用来告知果询优化器尽可能快地返回指定行数的数据行，即便这样做会防碍查询的整体性能。使 用这个提示的目的在于为使用者快速返回特定行数的记录，由此让他们产生速度非常快速的错觉。当返回 指定行数的数据行后，剩余的数据行按照它们通常的速度返回。因此，如果使用了 FAST提示,那么生成的执行计划只是基于那些F AST返回的数据行，而非查询要返回的 所有数据行。如