+ϩ

介绍了数据库方面的基础知识

处理来自客户机的语句时的另一种情况是，查询是作为 SQL 语言事件出现的。除了一点以外，此流程并无太大的差异。在这种情况下，SQL Server 试图使用称为自动参数化的技术。SQL 文本与自动参数化模板相匹配。自动参数化是个棘手的问题，因此，过去一直能够利用共享的 SQL 的其他数据库管理产品， 一般并没有提供这一选项。随之而来的问题是，如果 SQL Server 自动地参数化每个查询，那么对于随后提交的某些特定值而言，这些查询中的某些（或绝大多数）将获得非常糟糕的计划。在程序员将参数标记放在代码之中的场合下，其假定是程序员知道所期望的值的范围，并愿意接受 SQL Server 提供的计划。但当程序员实际补充一个特定的值，并且 SQL Server 决定将该值当做一个可变的参数来对待时，所产生的任何适合于某个值的计划可能不适合于后续的值。利用存储过程，通过在过程中放入 WITH RECOMPILE 选项，程序员可以强制产生新的计划。利用自动参数化，程序员无法指出必须为每一个新值开发新的计划。


当 SQL Server 处理自动参数化时，它是非常保守的。被安全地自动参数化的查询有一个模板，并且只有匹配模板的查询才能应用自动参数化。例如，假设有这样一个查询，其中包含带有等于操作符、但没有连接的 WHERE 子句，WHERE 子句中的列带有唯一的索引。SQL Server 知道绝对不会返回一行以上，而且计划将总是使用那个唯一的索引。SQL Server 绝对不会考虑扫描，实际值绝对不会以任何方式改变计划。对于自动参数化而言，这种查询是安全的。


如果查询匹配自动参数化模板，则 SQL Server 自动用参数标记（例如 @p1、@p2）代替文字，并且这就是我们发送到服务器的内容，正如它是 sp_executesql 调用一样。如果 SQL Server 认为该查询对自动参数化并不安全，则客户机将向 SQL Server 发送文字的 SQL 文本，以此作为特定的 SQL。


图 11 显示客户机向 SQL Server 发送请求时的处理流程。


[img]http://www.microsoft.com/china/msdn/library/techart/sqlquerproc11.gif[/img]


[B]图 11. 处理客户机的 SQL[/B]
[H2]编译[/H2]


现在让我们更详细地讨论一下编译和优化。在编译过程中，SQL Server 分析语句，并创建所谓的次序树，即语句的内部表述。这是 SQL Server 6.5 实际保留在 SQL Server 7.0 中的几个数据结构之一。该次序树是正常化的。正常化程序的主要功能是执行绑定。绑定包括检验表和列的存在，以及装载有关表和列的元数据。有关必需的（隐含的）转换信息也附加在次序树上，例如，如果查询试图向数字值添加整数 10，则 SQL Server 将向该树插入隐含的转换。正常化还用视图的定义代替对该视图的引用。最后，正常化执行一些基于语法的优化。如果该语句是传统的 SQL 语句，则 SQL Server 从关于该查询的次序树中提取信息，并创建称为查询图表的特殊结构，设置查询图表是为了使优化器工作非常有效。然后优化该查询图表，一个计划就产生了。


图 12 显示编译过程流程。


[img]http://www.microsoft.com/china/msdn/library/techart/sqlquerproc12.gif[/img]


[B]图 12. 编译[/B]
[H2]优化[/H2]


SQL Server 优化器其实是由独立的段组成的。第一段是一个非基于成本的优化器，称为琐细计划优化。琐细计划优化的完整概念是，当 SQL 语句确实只有一个可变计划时，基于成本的优化太昂贵了。最好的例子是，带 VALUES 子句的 INSERT 语句组成的查询。它只可能有一个计划。另一个例子是，所有的列都在唯一的封面索引（且没有其他列的索引）中的 SELECT 语句。这两例中，SQL Server 只要简单地生成一个计划，用不着在多个计划选一个更好的方案。琐细计划优化器可找到真正显而易见的计划，而且通常非常便宜。所以，最简单的查询在处理的前期就趋于被清除，优化器不花很多时间来搜索一个好计划。这是好事，因为随着 SQL Server 将杂凑连接、合并连接和索引相交增加到其处理技术列表上，SQL Server 7.0 版上的潜在计划数呈天文数字增长。


如果琐细计划优化器不能找到一个计划，SQL Server 便进入优化的下一部分，称为简化。简化是查询本身的语法变换，寻找可交换的特性和可重新排列的运算。SQL Server 可进行常数合并，以及无需考虑成本或分析索引是什么但能得出更有效查询的其他运算。SQL Server 然后上载关于索引和列的统计信息，并输入优化的最后的主要部分，即基于成本的优化器。


基于成本的优化有三个阶段。第一个基于成本的阶段，称为交易处理阶段，查找简单请求的计划，即典型的交易处理系统。这些请求一般比由琐细计划优化器处理的那些请求要复杂些，并要求比较众多计划查找出成本最低的计划。当交易处理阶段完成时，SQL Server 便将找到的成本最低的计划与内部阈值进行比较。阈值用于决定是否要求进一步的优化。如果计划成本比阈值低，那么，进行附加优化比只执行已找到的计划成本要高。所以，SQL Server 不做进一步优化，并使用交易处理阶段找到的计划。


如果交易处理阶段找到的计划，仍比该阶段的阈值贵，SQL Server 便进入第二个阶段。这个阶段有时称为 QuickPlan 阶段。QuickPlan 阶段扩大搜索范围来寻找一个好计划，包括选择好的、适度复杂的查询。QuickPlan 检查可能的计划范围，完成之后，将最佳计划的成本与第二个阈值进行比较。因为在交易处理阶段，如果发现了一个成本比阈值低的计划，优化便终止，并使用那个计划。一般来说，SQL Server 6.5 版中已有的查询的计划，在 SQL Server 7.0 版中也应当是最佳的，这个计划将要么被琐细计划优化器找到，要么被基于成本的优化的头两个阶段中的一个发现。这些规则被有意地组织起来以达到这个目的。这个计划将很可能由使用单一的索引和使用嵌套循环联合组成。


优化的最后阶段，称为完全优化，旨在对复杂和非常复杂的查询产生一个好计划。对复杂的查询来说，QuickPlan 产生的计划，经常被认为比继续搜索一个更好的计划要昂贵得多，而完全优化将被执行。在完全优化中，实际上有两个适用的独立选择。如果 QuickPlan 阶段产生的最佳成本比“并行成本阈值”的配置值要高，并且如果服务器是一个多处理器机器，那么优化器的最后阶段将涉及查找一个能在多个处理器上并行运行的计划。如果 QuickPlan 阶段的最佳计划的成本比配置的“并行成本阈值”低，那么，优化器将只考虑串行计划。完全优化阶段能执行各种可能性，而且很耗时，因为在这最后阶段必须找到一个计划。优化器仍可能没有检查每个可得到的计划，因为它将任何潜在的计划成本与优化中得出此结果的成本进行比较，并且它估算继续试用不同优化的可能成本。在某些情况下，优化器可能认为，使用现有的计划比继续查找更优方案还要便宜，而且支付继续优化的附加编译成本将不具备高的成本效率比。在这最后阶段处理的各种查询的计划一般只使用一次，所以，几乎没有这样的机会：为编译和优化所付出的额外代价，会在后续执行的计划重用中一次结清。那些后续执行很可能不会发生。


找到一个计划后，该计划便变为优化器的输出，然后 SQL Server 在执行该计划之前，遍历前面已讨论过的全部缓存机制。您应该意识到，如果完全优化阶段产生了该查询的并行计划，并不一定意味着该计划将在多个处理器上执行。如果机器很忙，而且不支持在多个 CPU 上运行单一的查询，该计划则使用单一的处理器。


图 13 显示了优化器的处理流程。


[img]http://www.microsoft.com/china/msdn/library/techart/sqlquerproc13.gif[/img]


[B]图 13. 优化[/B]
[H2]执行[/H2]


查询处理的最后一步是执行。除了这一小段外，我们不会再讨论执行的详细过程。执行引擎采用优化器生成的计划，并执行之。处理实际执行以外，执行引擎还为要运行的处理器调度线程，并提供线程间的通信。
[H2]摘要[/H2]


如前所述，SQL Server 的内部机制与结构是一个非常大的主题，远远超过了我们能在本文中提供的内容。我们重在直接介绍 SQL Server 与客户机的交互方式，以及 SQL Server 关系引擎如何处理来自客户机的请求。我们希望，在了解 SQL Server 如何处理查询，以及如何和何时编译或重新编译它们之后，您就能利用 SQL Server 7.0 的功能和技巧编写出更好的应用程序。