Microsoft SQL Server 查询处理器的内部机制与结构(1)
ubuntu 手机,怎样快速丰胸,皈依证查询
摘要：本文介绍了在客户机上处理 Microsoft SQL Server 查询的方式，各种客户机与 SQL Server 的交互方式，以及 SQL Server 在处理客户机程序的请求时需要完成的工作。(打印共 26 页）
简介
Microsoft(R) SQL Server(TM) 内部机制和结构是一个非常大的主题，因此本文仅限于
程序开发人员感兴趣的问题，集中研究其他源中没有彻底讨论的问题。在讨论 SQL Server 的结构时，我们主要观察客户机的处理过程，研究不同的客户机程序与 SQL Server 的交互方式，以及 SQL Server 如何处理客户机的请求。还有一些讨论 SQL Server 其他方面的信息源，特别是 Microsoft Press 出版的 Inside SQL Server 7.0，作者是 Ron Soukup 和 Kalen Delaney，这本书非常详细地讨论了 SQL Server 存储引擎的内部机制和处理方法，不过对查询处理器的讨论不够深入。本文正填补了这个空白。
我们期望本文有助于读者编写出更好的应用程序。通过本文，读者会在提高程序性能方面得到新的启发，产生新的理解。
SQL Server 是一种客户机/服务器
系统
多年来，SQL Server 一直被认为是一种客户机/服务器系统。事实上，
Sybase DataServer（以此为基础开发了原始的 SQL Server）正是第一个作为客户机/服务器系统开发的商用关系
数据库系统。那这又说明了什么呢？这不只意味着 SQL Server 是一个双层系统。从传统上看，双层系统意味着客户机应用程序运行在一台机器上，向另一台计算机上的服务器发送请求。而对于 SQL Server，客户机/服务器意味着 SQL Server 的组成部分，即客户机 API 部分，驻留在处理结构中的远端，与服务器
组件本身是分开的。
在典型的双层模型中，客户机程序部分驻留在台式机上，具有大量客户机应用程序逻辑和业务逻辑，并且会直接向数据库系统发出请求。然后，客户机得到服务器响应这些请求所返回的数据。
三层系统也采用了同样的模型。多年以来，SQL Server 一直用在事务处理监视系统中，例如 BEA 的 Tuxedo 以及 Compaq 的 ACMSxp，这些系统早在二、三十年前就采用了典型的三层模型。三层模型在今天基于 Web 的应用系统中占据了支配地位，这类系统以 Microsoft 的 MTS 以及新的 COM+ 1.0 为代表。从 SQL Server 的角度看，三层解决方案中的客户机程序是放在中间层的。中间层直接与数据库交互。实际的桌面，或瘦客户机(Thin Client)，使用其他机制并通常直接与中间层交互，而不是直接与数据库系统交互。图 1 描述了这种结构。
图 1. 三层系统模型
客户机结构
从结构的角度看，SQL Server 关系服务器组件本身并不真正关心客户机程序运行的位置。事实上，就 SQL Server 而言，即使在运行 SQL Server 的同一台机器上运行应用程序，仍然还是客户机/服务器模型。服务器运行一个单独的多线程进程，为来自客户机的请求提供服务，不管客户机的位置在哪里。客户机程序代码本身是单独的运行在客户机应用程序内部的 DLL，与 SQL Server 的实际接口是在客户机和服务器之间对话的“表格数据流”(Tabular Data Stream, TDS) 协议。
一个常见的问题是“什么是 SQL Server 的本机接口呢？”很长时间以来，很多开发人员一直都不愿意使用 ODBC 这样的接口，因为他们认为由 Sybase 开发的客户机 API，也就是 DB-Library，是 SQL Server 的本机接口。实际上，SQL Server 关系服务器本身并没有本机 API，它的接口就是在客户机和服务器之间的通信流协议 TDS。TDS 把客户机发送给服务器的 SQL 语句封装起来，也把服务器返回给客户机的处理结果封装起来。任何直接处理 TDS 的 API 都是 SQL Server 的本机接口。
让我们来看一下客户机的组件，如图 2 所示。客户机结构中的某些部分就不在这里讨论了，因为它们不属于 SQL Server 的范畴。但如果您在编写应用程序的话，就必须了解这些部分。大家知道得最多的应该是各种对象模型，如果您正在编写 ASP 或 Microsoft Visual Basic(R) 应用程序，就需要通过 ADO 与数据库系统交互，而不是直接调用底层的 API，例如 ODBC 或 OLE-DB。ADO 映射到 OLE-DB，而 RDO 映射到 ODBC。因此，作为这种最常用的
编程模型的对象模型，并不是 SQL Server 客户机结构中的严格意义上的组件。此外，还有另外一些组件可以插接到 SQL Server 基础结构上面的这一层。OLE-DB 的“会话池服务提供程序 (Session Pooling Service Provider)”就是这种组件的一个例子。
图 2. 客户机结构
客户机接口
SQL Server 有两个接口可以认为是 SQL Server 7.0 的本机接口，即 OLE-DB 和 ODBC。DB-Library 接口也是本机的，它与 TDS 通信，但是 DB-Library 使用的是 TDS 较老的版本，需要在服务器上进行一些转换。现有的 DB-Library 应用程序仍然可以继续与 SQL Server 7.0 协同使用，但是很多新的功能和性能提高等好处只能通过 ODBC 和 OLE DB 才能利用。更新 DB-Library 使其支持 SQL Server 7.0 的新能力，将会导致与现有应用程序的很多不兼容性，因此需要修改应用程序。ODBC 在五年之前就替代了 DB-Library，是新的 SQL Server 应用程序更理想的 API，因此引入不兼容的 DB-Library 新版本并不明智。
从图 2 可以看到，所有这些客户机 API 都有三个部分。最上面的部分实现 API 的细节，例如行集和游标应该是什么样等等。TDS 格式化程序负责处理实际请求，例如 SQL 语句，并将其封装成 TDS 消息包，发送给 SQL Server，获得返回的结果，然后再把结果反馈到接口实现。
还有一些供所有提供程序使用的公共库代码。例如，BCP 设备就是 ODBC 和 OLE-DB 都可以调用的库。DTC 也是这样。第三个例子是 ODBC 规范的 SQL 语法，即带有参数标记的 CALL 语法，这些对于所有提供程序都是通用的。
除了我们在前面已经提到的局限性，即 DB-Library 仍然只能使用 SQL Server 6.5 版，TDS 协议对于所有 API 都是相同的。ODBC 和 OLE-DB 在与 SQL Server 7.0 通信时使用 SQL Server 7.0 版，但也能够与 6.5 或 6.0 服务器通信。另一个是 Net-Library，这是一个抽象层，客户机和服务器都在此层上同网络抽象接口通信，不必为 IPX 还是 TCP/IP 困扰。在这里我们将不讨论 Net-Library 的工作细节；只要知道它们的工作基本上是将来自的网络通信底层的细节隐藏起来不让软件的其他部分看到就可以了。
从客户机的角度看服务器
前面已经提到过，客户机与 SQL Server 通信的主要方法就是通过使用 TDS 消息。TDS 是一种简单协议。当 SQL Server 接收到一条消息时，可以认为是发生了一个事件。首先，客户机在一个连接上发送登录消息（或事件），并得到返回的成功或失败的响应。当您希望发送 SQL 语句时，客户机可以把 SQL 语言消息打包发送给 SQL Server。另外，当您希望调用存储过程、系统过程或虚拟系统存储过程（我们后面还要详细讨论）时，客户机可以发送 RPC 消息，这种消息相当于 SQL Server 上的一个 RPC 事件。对于上面的后两种情况，服务器会以数据令牌流的形式送回结果。Microsoft 没有把实际的 TDS 消息写入文档中，因为这被认为是 SQL Server 组件之间的私用契约。
目录存储过程是另一类关键的客户机/服务器的交互部分。这些存储过程首先在 ODBC 的 SQL Server 6.0 中出现, 包括诸如 sp_tables 和 sp_columns 等存储过程。ODBC 和 OLE-DB API 定义了描述有关数据库对象的元数据的标准方法，这些标准需要适用于所有类型的 RDBMS 服务器，而不必调整为 SQL Server 自己的系统表。不是客户机向服务器发送对系统表的多个查询，并在客户机端建立标准的元数据视图，而是创建一组存储在服务器上的系统存储过程，并对 API 返回适当格式的信息。这种方法使得通过一次通信就可以完成很多重要的元数据请求。
为 ODBC 编写的过程已经写入文档，通常适合需要从系统表中获取信息但其他机制没有提供这种方法的情况。这使得 Transact-SQL 过程和 DB-Library 应用程序可以访问元数据，而不需要编写对 SQL Server 系统表的复杂查询，并且使应用程序不受今后 Microsoft 修改系统表的影响。
OLE DB 定义了一组架构行集，它们类似于 ODBC 的元数据，但又和它不同。它创建了一组新的目录存储过程，以更有效地为这些架构行集植入数据。但是，这组新的存储过程没有写入文档，因为这些存储过程重复了早先提供的功能。通过现有的若干种方法都可以得到元数据，因此 SQL Server 开发组决定不显露这些并没有为编程模型增加新内容的对象。
客户机与服务器的交互还有第三个方面。它最初出现在 SQL Server 6.0 中，但是没有得到普遍使用。这就是虚拟系统存储过程的概念；在 SQL Server 7.0 中起很重要的作用。当第一次为 SQL Server 6.0 开发服务器端游标时，开发人员就需要选择采取什么方法管理客户机/服务器的交互。游标并不特别适合现有的 TDS 消息，因为这些消息允许逐行返回数据，不需要客户机指定额外的 SQL 语句。开发人员本来可以向 TDS 协议添加更多的消息，但是需要修改太多的其他组件。SQL Server 6.0 中的 TDS 版本还需要向 Sybase 版本靠拢，以便确保两者的可互操作性，于是开发人员选择了另外的处理机制。他们开发了外表看起来像是系统存储过程的新功能（服务器端游标），实际上是指向 SQL Server 代码的入口存储过程。它们被客户机应用程序使用标准的 RPC TDS 消息来调用。它们被称为虚拟系统存储过程，因为在客户机上，它们像其他存储过程那样被调用，和其他存储过程不同的是，它们并不是由简单的 SQL 语句组成。大多数虚拟系统存储过程都是私用的，并且没有写入文档。对于游标过程，所有 API 都显露其自有的一组游标 API 模型和它们自己的游标操作函数，因此没有必要为存储过程本身编写文档。即使是在 Transact-SQL 语言中，也有显露游标的语法，可以使用 DECLARE、OPEN、FETCH 等，所以完全没有必
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！
点击进行留言回复
我要评论
网友评论