為什么在Access前端和SQL后端上使用復雜的SQL會比較慢？

Question

我了解在具有多個join語句的復雜查詢的情況下，最好使用直通查詢。 我的困惑是當不對復雜的sql語句使用直通查詢時會發生什么。

是因為ODBC驅動程序無法解析查詢並且SQL Server無法理解查詢並通過要由Access本身查詢的網絡管道發送所有數據，所以它很慢嗎？

要么

它是否很慢，因為即使ODBC驅動程序可以解析SQL語句，它也要花費很多時間

Answer 1

首先，如果傳遞查詢與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。