SQL Server查询处理器机制与结构(中)(1)

处理 SQL 语句时的客户机/服务器交互

下面我们将讨论当客户机应用程序与 SQL Server 交互时客户机的动作。以下是一个 ODBC 调用的例子：

　　
　　SQLExecDirect(hstmt, "SELECT * FROM parts where partid = 
　　
　　
　　7", SQL_NTS)
　

（OLE-DB 也有一个与这个调用几乎直接等价的调用，此处不再讨论这个调用，因为这个调用实际上与 ODBC 调用相同。）该 ODBC 调用取一个 SQL 语句，然后将其发送给 SQL Server 来执行。

在这个具体的查询语句中，我们从零件表中提取具有特定零件标识号的所有行。这是特定 SQL 的一个典型例子。在 SQL Server 7.0 以前的版本中，特定的 SQL 与存储过程的一个显著差别是，查询优化器所生成的计划从不缓存。查询语句要被读入、编译、执行，然后再抛弃计划。在 SQL Server 7.0 中，正如稍后还要讨论的，实际上提供了可以缓存特定查询语句的计划的机制。

在这条语句被送往 SQL Server 之前，还必须要问几个问题。所有客户机程序都要提供某种游标说明，所以客户机程序在内部必须询问的一个问题是，程序员请求的是什么样的结果集或什么样的游标。最快的类型是在文档中被称为默认结果集的游标。这种游标由于历史上的原因被称为消防站游标，有时甚至根本不把它作为游标看待。当 SQL 请求被送到服务器之后，服务器开始把结果返回给客户机，这个返回结果的过程持续进行，直到把全部数据集发送完毕为止。这就像一个将数据抽给客户机的大型消防站。

一旦客户机程序确定了这是默认结果集，则下一步就是确定是否有参数标记。使用这个 ODBC SQLExecDirect（以及 OLE-DB 中等价的调用）调用的选项之一是，不是在 WHERE 从句中给出像 7 这样的具体值，而是可以用一个问号来传递参数标记，如下所示：

　　
　　SQLExecDirect(hstmt, "SELECT * FROM parts where partid = 
　　
　　?", SQL_NTS)
　

请注意，您必须分别提供实际的参数值。

客户机需要知道 SQL 语句中是否有参数标记，或者它是否为真正特定的非参数化 SQL。这将影响到客户机将用这个语句在

准备/执行模型

除了执行直接模型（在 ODBC 中用 SQLExecDirect 调用）外，在 ODBC 和 OLE-DB 中，还有一种执行模型，称为准备/执行模型。定义要执行的 SQL，是作为一个独立于实际执行 SQL 的步骤来完成的。以下是 ODBC 中的一个例子：

　　SQLPrepare(hstmt, "SELECT * FROM parts where partid = 
　　
　　
　　?", SQL_NTS)
　　
　　SQLExecute(hstmt)
　

在 SQL Server 7.0 版本之前，准备/执行从来都不是 SQL Server 的本机模式。如今在 7.0 版本中，有两个提供本机接口的虚拟系统存储过程。对于准备调用，我们要再次研究游标的类型，然后调用 sp_prepare 或 sp_cursorprepare。这些过程会完成 SQL 或存储过程的编译，但不会实际执行计划。相反，虚拟系统存储过程只是返回该计划的句柄。现在，应用程序可以反复地执行 SQL 了，例如传入不同的参数值，而不需要重新编译。