Microsoft查询处理器的内部机制与结构

来源：互联网发布：发牌程序java 编辑：程序博客网时间：2024/05/23 19:19

摘要：本文介绍了在客户机上处理MicrosoftSQLServer查询的方式，各种客户机与SQLServer的交互方式，以及SQLServer在处理客户机程序的请求时需要完成的工作。

　　简介

　　Microsoft(R)SQLServer(TM)内部机制和结构是一个非常大的主题，因此本文仅限于程序开发人员感兴趣的问题，集中研究其他源中没有彻底讨论的问题。在讨论SQLServer的结构时，我们主要观察客户机的处理过程，研究不同的客户机程序与SQLServer的交互方式，以及SQLServer如何处理客户机的请求。还有一些讨论SQLServer其他方面的信息源，特别是MicrosoftPress出版的InsideSQLServer7.0，作者是RonSoukup和KalenDelaney，这本书非常详细地讨论了SQLServer存储引擎的内部机制和处理方法，不过对查询处理器的讨论不够深入。本文正填补了这个空白。

　　我们期望本文有助于读者编写出更好的应用程序。通过本文，读者会在提高程序性能方面得到新的启发，产生新的理解。

　　SQLServer是一种客户机/服务器系统

　　多年来，SQLServer一直被认为是一种客户机/服务器系统。事实上，DataServer（以此为基础开发了原始的SQLServer）正是第一个作为客户机/服务器系统开发的商用关系系统。那这又说明了什么呢？这不只意味着SQLServer是一个双层系统。从传统上看，双层系统意味着客户机应用程序运行在一台机器上，向另一台计算机上的服务器发送请求。而对于SQLServer，客户机/服务器意味着SQLServer的组成部分，即客户机API部分，驻留在处理结构中的远端，与服务器组件本身是分开的。

　　在典型的双层模型中，客户机程序部分驻留在台式机上，具有大量客户机应用程序逻辑和业务逻辑，并且会直接向数据库系统发出请求。然后，客户机得到服务器响应这些请求所返回的数据。

　　三层系统也采用了同样的模型。多年以来，SQLServer一直用在事务处理监视系统中，例如BEA的Tuxedo以及Compaq的ACMSxp，这些系统早在二、三十年前就采用了典型的三层模型。三层模型在今天基于Web的应用系统中占据了支配地位，这类系统以Microsoft的MTS以及新的COM+1.0为代表。从SQLServer的角度看，三层解决方案中的客户机程序是放在中间层的。中间层直接与数据库交互。实际的桌面，或瘦客户机(ThinClient)，使用其他机制并通常直接与中间层交互，而不是直接与数据库系统交互。图1描述了这种结构。

图1.三层系统模型

　　客户机结构

　　从结构的角度看，SQLServer关系服务器组件本身并不真正关心客户机程序运行的位置。事实上，就SQLServer而言，即使在运行SQLServer的同一台机器上运行应用程序，仍然还是客户机/服务器模型。服务器运行一个单独的多线程进程，为来自客户机的请求提供服务，不管客户机的位置在哪里。客户机程序代码本身是单独的运行在客户机应用程序内部的DLL，与SQLServer的实际接口是在客户机和服务器之间对话的“表格数据流”(TabularDataStream,TDS)。

　　一个常见的问题是“什么是SQLServer的本机接口呢？”很长时间以来，很多开发人员一直都不愿意使用ODBC这样的接口，因为他们认为由Sybase开发的客户机API，也就是DB-Library，是SQLServer的本机接口。实际上，SQLServer关系服务器本身并没有本机API，它的接口就是在客户机和服务器之间的通信流协议TDS。TDS把客户机发送给服务器的SQL语句封装起来，也把服务器返回给客户机的处理结果封装起来。任何直接处理TDS的API都是SQLServer的本机接口。

　让我们来看一下客户机的组件，如图2所示。客户机结构中的某些部分就不在这里讨论了，因为它们不属于SQLServer的范畴。但如果您在编写应用程序的话，就必须了解这些部分。大家知道得最多的应该是各种对象模型，如果您正在编写或Microsoft(R)应用程序，就需要通过ADO与数据库系统交互，而不是直接调用底层的API，例如ODBC或OLE-DB。ADO映射到OLE-DB，而RDO映射到ODBC。因此，作为这种最常用的模型的对象模型，并不是SQLServer客户机结构中的严格意义上的组件。此外，还有另外一些组件可以插接到SQLServer基础结构上面的这一层。OLE-DB的“会话池服务提供程序(SessionPoolingServiceProvider)”就是这种组件的一个例子。1