我了解到，对于具有多个join语句的复杂查询，最好使用直通查询。我的困惑是当我们不对复杂的sql语句不使用传递查询时会发生什么。
由于ODBC驱动程序无法解析查询并且SQL Server无法理解查询并通过要由Access本身查询的网络管道发送所有数据，所以速度很慢
OR
它是否很慢，因为即使ODBC驱动程序可以解析SQL语句，它也要花费很多时间
答案 0 :(得分：4)
首先，如果将传递查询与ODBC驱动程序一起使用，则Access本身不会尝试解析查询，而是将其发送到通过ODBC驱动程序访问数据库。这样，就可以使用服务器可以理解的本地SQL方言提交查询。这允许提交Access无法执行的专门和/或高度优化的查询。此外，此类查询还可以引用未链接到Access的服务器表（和其他对象）。
对于“普通” Access查询（不是传递），Access数据库引擎将尝试根据其自身的功能来解析，解释和优化查询。为此，Access将构造一个或多个查询，并将其也通过ODBC驱动程序发送到服务器。从服务器接收到数据后，它将对数据应用所有残留连接和条件，以满足整体SQL语句-这是由Access在本地完成的，与远程服务器。
正如其他人所评论的那样，有时Access可能足够聪明，可以指示远程服务器执行一些联接或应用某些条件（例如WHERE条件），但是Access引擎不够聪明，无法始终选择最佳优化。当查询同时包含Access表和远程表的源表时，尤其如此。这些限制正是为什么传递查询作为选项存在的原因，以便程序员可以干预将优化的查询发送到服务器，然后在以后使用其他Access查询执行其他联接和条件。
因此，发送到服务器的任何查询都必须通过ODBC驱动程序。正确的是，ODBC驱动程序将对语句进行一些初始解析，以便它可以处理参数等，但是语句解析只是有效的数据库操作的开始。数据库引擎存储有关索引，约束，关系等的详细信息。它使用此类元数据来有效地检索，合并和排序数据，但是它通过将元数据与表一起存储来实现。因此，远程服务器将具有Access无法利用的所有元数据。 Access和SQL Server（以及任何其他RDBMS）具有不同的数据库引擎，并且不旨在交换基础元数据（例如索引，约束-如前所述）。值得注意的是，有时可以指定最少的信息（例如主键）来帮助Access更有效地使用远程表，但这实际上是最小的，并且不能提供有保证的高效数据操作。
针对“多年来的查询效率”的评论...
事实是Access在很大程度上是一种较旧的技术，具有非常基础的关系数据库功能，主要为本地数据库构建。它从未被设计为针对远程数据操作进行优化。此外，Access和SQL Server（或任何其他RDBMS）的基础数据库引擎不兼容。它们每个都有自己的存储数据和元数据的方式。唯一的互操作性来自您所知道的SQL语句，并且在前面的段落中已进行了讨论。没有标准的SQL术语来交换必要的复杂元数据以完全优化Access和远程服务器之间的查询，至少没有超出标准的JOINS和WHERE条件。
但是，期望这些年来的进展是完全合理的。先进的数据库服务器（包括SQL Server）确实支持跨远程服务器复制数据表和其他对象的方法。在这种情况下，可以设计出高效的查询，这些查询从分布在多个服务器上的表中请求数据。因此，对进展的期望的最终答案将是替换诸如Access之类的旧技术，并实现更新，更复杂和功能强大的数据服务器。这并不意味着对Access有轻微的影响，只是意味着即使在使用了很多年之后，Access也不会有太大变化。新的数据存储和检索技术正在更新，而不是Access。