∙    Table Scan(表扫描)：如果看到这个信息，就说明数据表上没有聚集索引，或者查询优化器没有使用索引来查。意即资料表的每一行都被检查到。如果资料表相对较小的话，表扫描可以非常快速，有时甚至快过使用索引。
因此，当看到有执行表扫描时，第一件要做的事就是看看数据表有多少数据行。如果不是太多的话，那么表扫描可能提供了最好的总体效能。但如果数据表大的话，表扫描就极可能需要长时间来完成，查询效能就大受影响。在这种情况下，就需要仔细研究，为数据表增加一个适当的索引用于这个查询。
假设你发现某查询使用了表扫描，有一个合适的非聚集索引，但它没有用到。这意味着什么呢？为什么这个索引没有用到呢？如果需要获得的数据量相对数据表大小来说非常大，或者数据选择性不高(意味着同一个字段中重复的值很多)，表扫描经常会比索引扫描快。例如，如果一个数据表有10000个数据行，查询返回1000行，如果这个表没有聚集索引的话，那么表扫描将比使用一个非聚集索引更快。或者如果数据表有10000个数据行，且同一个字段(WHERE条件句有用到这个字段)上有1000笔重复的数据，表扫描也会比使用非聚集索引更快。
查看图形执行计划上的数据表上的弹出式窗口时，请注意”预估的资料行数(Estimated Row Co
unt)”。这个数字是查询优化器作出的多少个数据行会被返回的最佳推测。如果执行了表扫描且”预估的数据行数”数值很高的话，就意味着返回的记录数很多，查询优化器认为执行表扫描比使用可用的非聚集索引更快。
∙    Index Seek(索引查)：索引查意味着查询优化器使用了数据表上的非聚集索引来查数据。性能通常会很快，尤其是当只有少数的数据行被返回时。
∙    Clustered Index Seek(聚集索引查plsql developer怎么执行语句)：这指查询优化器使用了数据表上的聚集索引来查数据，性能很快。实际上，这是SQL Server能做的最快的索引查类型。
∙    Clustered Index Scan(聚集索引扫描)：聚集索引扫描与表扫描相似，不同的是聚集索引扫描是在一个建有聚集索引的数据表上执行的。和一般的表扫描一样，聚集索引扫描可能表明存在效能问题。一般来说，有两种原因会引此聚集索引扫描的执行。第一个原因，相对于数据表上的整体数据行数目，可能需要获取太多的数据行。查看”预估的数据行数量(Estimated Row Count)”可以对此加以验证。第二个原因，可能是由于WHERE条件句中用到的字段选择性不高。在任何情况下，与标准的表扫描不同，聚集索引扫描并不会总是去查数据表中的所有数据，所以聚集索引扫描一般都会比标准的表扫描要快。通常来说，要将聚
集索引扫描改成聚集索引查，你唯一能做的是重写查询语句，让语句限制性更多，从而返回更少的数据行。
绝大多数情况下，查询优化器会对连接进行分析，按最有效率的顺序，使用最有效率的连接类型来对数据表进行连接。但并不总是如此。在图形执行计划中你可以看到代表查询所使用到的各种不同连接类型的图标。此外，每个连接图标都有两个箭头指向它。指向连接图标的上面的箭头代表该连接的外部表，下面的箭头则代表这个连接的内部表。箭头的另一头则指向被连接的数据表名。
有时在多表连接的查询中，箭头的另一头指向的并不是一个数据表，而是另一个连接。如果将鼠标移到指向外部连接与内部连接的箭头上，就可以看到一个弹出式窗口，告诉你有多少数据行被发送至这个连接来进行处理。外部表应该总是比内部表含有更少的数据行。如果不是，则说明查询优化器所选择的连接顺序可能不正确(下面是关于这个话题的更多信息)。
首先，让我们来看看连接类型。SQL Server可以使用三种不同的技术来连接资料表：嵌套循环(nested loop)，散列(hash)，以及合并(merge)。一般来说，嵌套循环是最快的连接类型，但如果不可能使用嵌套循环的话，则会用到散列或者合并作为合适的连接类型。两者都比嵌
套循环连接慢。
当连接大表时，则合并连接可能是最佳选项，而非嵌套循环连接。唯一的明确这一点的方式是对两者都进行测试以查看哪一个最有效率。
如果你怀疑某个查询速度慢的原因可能是因为它所使用的连接类型不理想，那么你可以使用连接提示来复盖查询优化器的选择。在使用连接提示之前，你需要花费一些时间去了解一下每种连接类型以及它们的工作方式。这是一个复杂的话题，超出了本文的讨论范围。
查询优化器选择最有效率的连接类型来连接数据表。例如，嵌套循环连接的外部表应该是连接的两个表中较小的那个表。散列连接也是一样，它的外部表应该是较小的那个表。如果你觉得查询优化器选择的连接顺序是错误的，可以使用连接提示来复盖它。
很多情况下，唯一的确认使用连接提示改变连接类型或连接顺序是提升还是降低了效能的方式，就是对它们进行测试，看看发生了什么。[7.0, 2000, 2005]
如果你的SQL Server有多个CPU，并且没有修改SQL Server的默认设置来限制SQL Server使用服务器上所有CPU的能力，那么查询优化器会考虑使用平行处理(parallelism)来执行某
些查询。平行处理指在多个CPU上同时运行一个查询的能力。很多情况下，一个运行在多个处理器上的查询比仅运行在单个处理器上的查询要快，但并不总是这样。
查询优化器并不会总是使用平行处理，即使在它能使用的时候。这是因为查询优化器在决定使用平行处理前会考虑到各种不同的因素。例如当前SQL Server上处于活动状态的连接数量，CPU忙碌程度，是否有足够的内存来运行平行化查询，需要处理的数据行数量，以及这个查询的类型。查询优化器收集到这些真实的数据后，再决定平行处理是不是运行这个查询的最佳选择。你可能会发现，某次一个查询没有用到平行处理，但稍后某次再次运行同样的查询时，却又用到了平行处理。
有时，使用多个处理器所需的花费会大于使用它们能所能节省的资源。尽管查询处理器的确会衡量使用平行查询的正反两面的影响，但它的猜想并不总是正确的。
如果怀疑平行处理防碍了某条查询的性能，你可以使用OPTION (MAXDOP 1)提示来关闭该查询的平行处理。
决定是否使用平行处理的唯一方式是通过这两种方式对查询进行测试，看看发生了什么。[7.0, 2000, 2005]
*****
查看图形执行计划时，你可能会发现某个图标的文字用红显示，而非通常情况下的黑。这意味着相关的表的一些统计数据遗失，统计数据是查询优化器生成一个好的执行计划所必须的。
遗失的统计数据可以通过右键这个图标，并选择”创建遗失的统计资料”来创建。这时会弹出”创建遗失的统计数据”对话框，通过它可以很容易地创建遗失的统计数据。
当可以选择去更新遗失的统计资料时，应该总是这样做，因为这样极有可能让你正在分析的查询语句从中获得效能上的好处。[7.0, 2000, 2005]
*****
有时你会在图形执行计划上看到标识了”Assert”的图标。这意味着查询优化器正在验证查询语句是否有违反引用完整性或者条件约束。如果没有，则没有问题。但如果有的话，查询优化器将无法为该查询建立执行计划，同时会产生一个错误。[7.0, 2000, 2005]
*****
你常常会在图形执行计划上看到标识成”书签查(Bookmark Lookup)”的图标。书签查相当常见。书签查的本质是告诉你查询处理器必须从数据表或者聚集索引中来查它所需要的数据行，而不是从非聚集索引中直接读取。
打比方说，如果一个查询语句的SELECT,JOIN以及WHERE子句中的所有字段，都不存在于那个用来定位符合查询条件的数据行的非聚集索引中，那么查询优化器就不得不做额外的工作在数据表或聚集索引中查那些满足这个查询语句的字段。
另一种引起书签查的原因是使用了SELECT *。由于在绝大多情况下它会返回比你实际所需更多的数据，所以应该永不使用SELECT *.
从性能方面来说，书签查是不理想的。因为它会请求额外的I/O开销在字段中查以返回所需的数据行。
如果认为书签查防碍了查询的性能，那么有四种选择可以用来避免它：可以建立WHERE子句会用到的聚集索引，利用索引交集的优势，建立覆盖的非聚集索引，或者(如果是SQL Server 2000/2005企业版的话)可以建立索引视图。如果这些都不可能，或者使用它们中的任
何一个都会耗用比书签查更多的资源，那么书签查就是最佳的选择了。[7.0, 2000, 2005]
有时查询优化器需要在tempdb数据库中建立临时工作表。如果是这样的话，就意味着图形执行计划中有标识成Index Spool, Row Count Spool或者Table Spool的图标。
任何时候，使用到工作表一般都会防碍到性能，因为需要额外的I/O开销来维护这个工作表。理想情况下应该不要用到工作表。不幸的是并不能总是避免用到工作表。有时当使用工作表比其它选择更有效率时，它的使用实际上会增强性能。
不论何种情况，图形执行计划中的工作表都应该引起你的警觉。应该仔细检查这样的查询语句，看看是否有办法重写查询来避免用到工作表。有可能没有办法。但如果有的话，你就朝提升这个查询的性能方面前进了一步。[7.0, 2000, 2005]。
*****
在图形执行计划上看到流聚合(Stream Aggregate)图标就意味着有对一个单一的输入进行了
聚合。当使用了DISTINCT子句，或者任何聚合函数时，如AVG, COUNT, MAX, MIN,或者SUM等，流聚合操作就相当常见。 [7.0, 2000, 2005]
****
查询分析器与Management Studio不是唯一的可以生成、显示查询执行计划的工具。SQL Server Profiler也可以显示执行计划，但格式是文本形式的。使用SQL Server Profiler来显示执行计划的一个优势是，它能为实际运行的大量查询产生执行计划。如果使用查询分析器和Management Studio，则一次只能运行一个。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。