訪問連接到 Azure SQL Server 后端的本地前端非常慢

Question

我一直在使用 Access 對數據庫進行快速原型設計。 現在我想做一個小組在線測試，所以我拆分數據庫並將后端放在 Azure SQL Server 上，然后重新鏈接。 它非常慢，而且我已經研究了好幾天的解決方案，但沒有得到積極的結果。 我的本地環境是Win10，Office2016 64bit，網絡連接又快又穩定。

我嘗試了不同的 ODBC 驅動程序，包括 SQL Native Client v11。

我在 NIC 上禁用了自動調整級別。

我已經從服務器上的訪問中重新創建了所有查詢。

我確保 ODBC 中的跟蹤已關閉。

但是我暫時啟用了跟蹤以查看發生了什么。 如果我打開前端，登錄（小用戶表），並在第一個表單上做了一些事情（添加 1 條記錄和 3 條子記錄......真的......根本沒有花哨或沉重的東西，這只需要1分鍾）然后關閉數據庫，我看到跟蹤日志文件是1.5MB。

所以我創建了一個空的 Access 文件和一個僅指向 User 表（12 列，20 條記錄）的 ODBC 鏈接，然后再次監視跟蹤日志文件。 打開訪問權限不會向日志文件添加任何內容，但打開這個鏈接表會使日志文件增長到 255kb。 在訪問中打開此表需要 5 秒鍾。

Access 向服務器發送了大約 800 個請求，僅用於打開這個小表。 如果我將所有用戶表數據粘貼到一個文本文件中，它只有 2kb。 那么為什么這么慢呢？

關於此的任何想法，特別是其他建議以使其更快地工作？

親切的問候，

Answer 1

好吧，使用 Azure 比運行連接到 SQL 服務器本地實例的 Access 慢的原因是，慢就是慢！

我的意思是，如果你要旅行 30 英里，你可以選擇步行或開車。

所以這里是你需要知道的問題：

為什么走路比開車慢？

答：因為你的速度比較慢！

那么為什么使用 Azure 比使用在本地計算機或本地網絡上運行的 SQL 服務器實例慢呢？

答：因為與 Azure 的連接速度要慢 100 倍左右！

這里的想法是，您不會考慮連接速度的差異，這就是這里的問題。 如果讀者認為這樣的設置（PC 上的訪問前端到 SQL 服務器的 Azure 實例）不是可行的設置，那么這對閱讀公眾是一種傷害。

所以這里的第一個問題是記下您與后端數據庫的連接速度。

典型的辦公室局域網的速度為 100mbits，或者今天大多數速度為 1gig——即使是您在 Best Buy 購買的 el-cheapo 路由器現在的額定速度也為 1gig (1000 mbits)。

但是，您的典型高速互聯網的額定速度約為 5 或 10 兆比特。 所以這慢了 100 倍。 （實際上 1000/5 = 慢 200 倍！！！）。

這意味着如果現在使用 Access 和 SQL 服務器在您的辦公網絡上需要 3 秒鍾？ 那么一個 WAN（通過互聯網），那么你需要通過連接速度的變化來增加時間（這很簡單 - 但它似乎逃脫了一切！）。 因此，如果幸運的話，您的互聯網速度可能會達到 5 兆位。 那意味着你去

1000 / 5 = 200

現在，您將 200 乘以現有的延遲，例如 3 秒，您將得到 600 秒（如果您想知道，那就是 10 分鍾！）。 所以你從 3 秒到 10 分鍾！

這種速度上的比較，就像走進一家體育用品店，購買橡皮艇橫渡大西洋。 因此，不考慮互聯網速度的變化並想知道為什么事情變慢是這里的問題。

您當然可以使用 Access to Azure，但您必須了解兩個簡單的概念。

1. 使用比 LAN 慢 50 到 200 倍的連接進行連接和測試是運行速度慢 50 到 200 倍的測試！ 與廣域網相比，沒有提及和考慮局域網的速度連接的巨大差異是這里的一個簡單問題。
2. 打開綁定到大數據表的表單會導致性能問題。

我正坐在公交車站和一位 90 歲的老奶奶交談。 我問她以下問題：

你用過即時取款機嗎？ 她說，為什么是的，我一直在使用它們。

然后我在這里問，你不覺得在你等待的時候讓櫃員機下載所有的人的賬戶然后問你你的賬號是不是很糟糕？

老太太說，當然，那是愚蠢的。 我輸入我的賬戶密碼，機器只下載我的賬戶信息——這很實用而且很明顯。

換句話說，那位老太太意識到，在用戶輸入或做任何事情之前下載一堆數據都是在浪費帶寬。

因此，您永遠不想啟動綁定到表的表單，然后詢問用戶要處理的記錄。 為什么 Access 將大量記錄下載到表單中，然后詢問用戶或允許用戶導航到所需的記錄？

即使在使用 Google 時，它​​也不會將整個互聯網下載到您的網絡瀏覽器頁面，然后您可以使用ctrl + f來搜索該網頁的內容。

相同的概念應該應用於 Access 應用程序。 詢問要處理的內容然后啟動綁定到帶有“where”子句的表的表單的設計將因此解決此問題。

因此，如果您有一個顯示客戶發票的表單（甚至是一個子表單），您將首先詢問發票編號，然后使用 where 子句簡單地啟動該表單，該子句將表單限制為 ONE 發票！

請記住，您仍然可以使用綁定到 100 萬行表的發票表單，如果使用where子句，則只有一條記錄將被拉下網絡連接*。

因此，典型的 Internet 連接具有足夠的速度來運行瀏覽器，並且還具有足夠的帶寬速度來下拉一些記錄。 Access 經常因性能不佳而受到批評，但這只是因為 Access 開發人員忽略了一個明顯的建議，即將大量您不需要的東西下載到表單中會運行緩慢。

因此，基於 Web 的應用程序，甚至是用 vb.net 編寫的桌面應用程序，在雲中運行的 SQL Azure 通過速度較慢的互聯網連接運行良好，因為這些應用程序不會啟動綁定到大型數據集的表單，而無需首先簡單地允許用戶請求什么他們需要看到和查看。

至於訪問和使用 SharePoint？ 該設置可能非常快，實際上比 SQL Azure、MySQL 或任何傳統數據庫系統快得多，因為當您使用 SharePoint 表和 Access 時，Access 會自動同步本地數據的副本。 此設置意味着您的應用程序將在沒有任何互聯網連接的情況下繼續運行。 一旦連接恢復，數據同步就可以恢復。

這意味着，如果您有一個包含 15,000 行的表並針對該數據運行報告，該報告可以通過 SharePoint 后端即時運行和啟動，因為數據的本地副本始終存在於前端！ 因此，此設置非常適合離線模式，或者在您的 Internet 連接不佳且速度緩慢的情況下，因為如上所述，您始終擁有數據的本地副本 – 只有在更改記錄時才會發生同步，並且該同步可以獨立於 Access 發生。 因此，您更改了一條記錄 - 它開始與 SharePoint 同步。

但是，對於必須更新的較大數據集，SQL Server 會好得多，因為您可以在 10,000 行上執行 sql 更新，並且在使用 SQL Server 時需要發生零網絡流量和數據傳輸來更新這 10,000 行（通過查詢）並且在使用 SharePoint 時，10,000 行將通過網絡傳輸，因為本地副本需要更新行。 因此，對於必須更新大量行或執行大量行更新類型的數據處理的應用程序，將 SharePoint 用於數據庫后端的巨大優勢不存在。

所以這里的關鍵概念和帶走：

您擁有的高速互聯網連接通常比典型的廉價辦公室（本地）網絡慢 10-200 倍。 所以這意味着 2 秒的操作現在需要 10-200 倍的時間。

需要優化 Access 應用程序以避免將太多記錄加載到表單中。 因此，構建搜索表單等。首先詢問用戶他們需要做什么是所有優秀開發人員（包括 Access 開發人員）的基本且簡單的要求。

Access 和 SharePoint 可能是最佳選擇，這樣的設置允許應用程序即使在沒有 Internet 連接的情況下也能運行。 如果表大小低於 10,000 行，那么這種設置通常是理想的。 然而，對於必須更新大量行的應用程序和數據處理繁重的應用程序，這種設置很差，因為對任何行的更新都會導致數據同步發生在網絡上。 這種設置也是最便宜的，因為一個支持 Access 的 SharePoint 支持的 Office 365 帳戶每月只需 6 美元，而 6 美元的帳戶最多允許 500 個免費用戶，這 500 個用戶甚至可以使用他們的 Gmail 或非 Microsoft 帳戶對於此設置。 與在 Internet 上使用 SQL Server 相比，適合 SharePoint 表范圍的此類訪問應用程序往往需要更少的更改和優化。

使用 SQL Server，使用視圖、通過嚴格的查詢以及在某些情況下編寫存儲過程允許更新和代碼在不使用任何帶寬的情況下運行。 因此，可以向更新 10,000 行數據的服務器發送單個更新查詢——唯一的網絡成本將是發送該 sql 語句的“微小”帶寬。

因此，雖然綁定表單可以與在雲中運行的 SQL Azure 一起使用，但需要構建類似於 Web 或 vb.net 的軟件，在其中他們首先詢問用戶要使用的帳戶或客戶，然后啟動 UI顯示給定的數據。

因此，在訪問中，您構建了一個搜索表單，如下所示：

因此，歸根結底，重要的是忽略此處暗示在雲中訪問 SQL 不可行的帖子。 通過與 Azure 上運行的 SQL 服務器的典型 Internet 連接，使用適當設計的訪問將工作得很好。

事實上，我看到人們通過 56k 調制解調器使用 Access to SQL！

必須采用明智的設計，其中為給定任務提取的數據受到限制——這是所有開發人員的標志——唯一的問題是 Access 不強制執行這種方法，而大多數其他開發人員工具不允許你掛起自己諸如將表格綁定到大桌子之類的東西！ 並不是 Access 很慢，而是當您做出糟糕的設計決策時 Access 很慢。

訪問 SharePoint 可能是一個真正的贏家——尤其是在帶寬不足、帶寬不穩定的情況下，即使在連接丟失時，如果您使用 SQL 后台運行相同的應用程序，應用程序將繼續運行並且運行速度超過 99% 的情況結束。 這里有一個很大的警告，因為只有某些類型的應用程序可以很好地與 SharePoint 表配合使用。 對我來說，解釋這些應用程序更好的原因、方式和時間超出了這里的一個簡單帖子，但人們只需要意識到 SharePoint 可以是令人難以置信的解決方案，但並非適用於所有應用程序，並且 SQL Server 可以並且將是更好的選擇. 這個 SharePoint“更好”的選擇只能根據給定類型的應用程序的個案評估來確定。

Answer 2

問題很簡單，與例如托管在中等現代服務器上的內部 SQL Server 實例相比， Azure SQL 數據庫在使用小型DTU（數據庫事務單元）時運行速度不是很快。

我也檢查了它，它需要非常仔細地設計查詢和過濾 - 遠非您通常可以逃脫的 - 以獲得可接受的整體速度。 另一方面，這是一種給予的體驗，它將把注意力集中在你可能不會遇到的潛在瓶頸上，否則可能為時已晚。

Answer 3

好的，所以經過將近一周的嘗試使其工作（Azure 上 SQL Server 后端的訪問前端）后，我得出的結論是它不是一個可行的解決方案。

我嘗試過 SQL Server，並在 Azure 上設置了一個 Sharepoint 2016 服務器，但也失敗了。

有效的是使用 Bullzipp 的一個名為 MS Access 到 MySQL 的產品來轉換訪問表，然后在服務器上添加一個 MySQL DB 並導入 Bullzip 生成的文件。 這里唯一需要注意的是 Bullzip 不喜歡較新的訪問格式（它需要一個 MDB 文件），所以轉到 Access，創建一個新的空文件，但請確保將其文件類型設置為 MDB。 然后導入您的表並運行 Bullzip。

它現在的運行速度比 SQL Server 快得多，但是我在 Access 中遇到了一些寫沖突，所以我只需要檢查代碼並做我需要做的任何事情，這樣我就可以避免這些消息。

Answer 4

使用 Access 作為 Azure SQL 表的前端是最糟糕的解決方案。 但是，有時你必須這樣做。 我有一個客戶堅持要保留她的 Access 數據庫。 當她雇用她的第一個員工時，很明顯她需要在屏幕后面對表進行 SQL 處理。

這是一場噩夢。 然而，在重新設計了一些糟糕的表結構、創建視圖和許多過程之后，我已經能夠做到了。 在某些情況下，我使用本地表，並通過從存儲的過程中提取並插入本地表來重新填充。 我使用鏈接表進行基本數據編輯，並且幾乎經常進行顯式保存記錄。

我還有一個首次加載模塊，它打開所有表單，轉到最后一條記錄，返回第一條記錄，然后在需要時隱藏表單。 負載跛行約 3

我唯一剩下的問題是，Azure 將在（我認為）30 分鍾或更長時間的空閑時間后關閉連接——或者可能是筆記本電腦休眠的時候？ 這會殺死應用程序，必須關閉並重新打開它。