访问连接到 Azure SQL Server 后端的本地前端非常慢

Posted 2023-05-07

【中文标题】访问连接到 Azure SQL Server 后端的本地前端非常慢

【英文标题】：Access local front-end connected to Azure SQL Server back-end very slow

【发布时间】：2016-09-30 14:08:18

【问题描述】：

我一直在使用 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。在 access 中打开此表需要 5 秒钟。

Access 向服务器发送了大约 800 个请求，仅用于打开这张小表。如果我将所有用户表数据粘贴到一个文本文件中，它只有 2kb。那么为什么这么慢呢？

对此有什么想法，特别是有其他建议可以让这个工作更快吗？

亲切的问候，

【问题讨论】：

如果理解正确，您正在尝试使用 Access 前端和 SQL 后端，并且连接不是通过 LAN 而是通过 Internet？ Access 不是为此而设计的，我对它慢到无法使用的程度并不感到惊讶。您可以通过使用视图、函数和存储过程尽可能多地使用服务器端来缓解一些问题，但即使这样通常也可以使其在 LAN 上运行正常。

Access 发送了大约 800 个请求！ 您的应用程序或 odbc 连接器行为不端。Access 可以处理 Internet 上的 odbc 链接表，您应该不会有任何问题'已经描述了。

是的....800 个请求。这就是他们的样子：-------------------------------------------- -------- DB 连接 t 28a0-283c ENTER SQLSetConnectOptionW HDBC 0x00000253AB74E730 SQLINTEGER 101 SQLPOINTER 1 --------- ------------------------------ DB 连接 t 28a0-283c 退出 SQLSetConnectOptionW 并返回代码 0 (SQL_SUCCESS) HDBC 0x00000253AB74E730 SQLINTEGER 101 SQLPOINTER 1

@SunKnight0：你很困惑。 ODBC 连接也被设计为在 WAN 上工作，并且确实如此。您评论的是链接 Access 表的使用；这些在慢速 WAN 上效果不佳。但是，像 100 Mbit/s 和低延迟的光纤连接这样的稳定​​ WAN 将完全可以正常工作。

re: “访问向服务器发送了大约 800 个请求” - 如果您正在谈论通过“ODBC 数据源管理器”的“跟踪”选项卡跟踪 ODBC 流量对话框，并且您将每个 ENTER SQLGetData / EXIT SQLGetData 对计为一个“请求”，那么您误解了跟踪结果。这些是低级 ODBC 调用，用于解压缩从客户端到服务器的一些实际请求（可能只有一个）返回的 每一行 的每个字段。像 Wireshark 这样的工具可以让您更真实地了解应用程序生成的网络流量。

【参考方案1】：

嗯，使用 Azure 比运行连接到本地 SQL 服务器实例的 Access 慢的原因是，慢就是慢！

我的意思是，如果你要旅行 30 英里，你可以选择步行或开车。

所以这是你需要知道的问题：

为什么走路比开车慢？

答案：因为您的行驶速度较慢！

那么，为什么使用 Azure 会比使用在本地计算机或本地网络上运行的 SQL Server 实例更慢？

回答： 因为到 Azure 的连接速度大约慢了 100 倍！

您不考虑连接速度差异的想法是这里的问题。如果读者认为这样的设置（PC 上的前端访问 SQL 服务器的 Azure 实例）不是一个可行的设置，这对读者来说是一种伤害。

所以这里的第一个问题是记下您与后端数据库的连接速度。

典型的办公室局域网速度为 100 兆比特，或者如今大多数为 1 吉格——即使您在百思买购买的 el-cheapo 路由器现在的额定速度为 1 吉格（1000 兆比特）。

但是，您的典型高速互联网的额定速度约为 5 或 10 mb。所以这慢了 100 倍。 （实际上 1000/5 = 慢了 200 倍！！！）。

这意味着如果现在使用 Access 和 SQL Server 在您的办公网络上花费 3 秒时间？然后是一个 WAN（通过互联网），然后你需要通过改变连接速度来倍增时间（这很简单——但它似乎完全逃脱了！）。所以，如果你幸运的话，你的互联网速度可能会达到 5 mbs。这意味着你走了

1000 / 5 = 200

您现在取 200 和现有延迟的倍数，例如 3 秒，得到 600 秒（如果您想知道，那就是 10 分钟！）。所以你从 3 秒缩短到 10 分钟！

这种速度上的比较就像走进一家体育用品店购买橡皮艇横渡大西洋一样。因此，不考虑互联网速度的变化并想知道为什么速度很慢是这里的问题。

您当然可以使用 Access to Azure，但您必须了解两个简单的概念。

使用比 LAN 慢 50 到 200 倍的连接进行连接和测试是运行速度会慢 50 到 200 倍的测试！与 WAN 相比，没有提及和考虑 LAN 连接速度的巨大差异是一个简单的问题。 打开绑定到大型数据表的表单会出现性能问题。

我正坐在公交车站与一​​位 90 岁的老奶奶交谈。我问了她以下问题：

你用过即时取款机吗？ 她说，为什么是的，我一直在使用它们。

然后我在这里问你，你不觉得让柜员机在你等待的时候下载所有的人的账户，然后问你你的账号是不是很糟糕？

老太太说，当然，那是愚蠢的。我输入我的帐户密码，机器只下载我的帐户信息——这既实用又明显。

换句话说，那位老太太意识到，在用户输入或执行任何操作之前下载大量数据是浪费带宽。

因此，您永远不想启动绑定到表的表单，然后询问用户要处理的记录。为什么要让 Access 将大量记录下载到表单中，然后询问用户或允许用户导航到所需的记录？

即使使用谷歌，它也不会将整个互联网下载到您的网络浏览器页面中，然后您可以使用 ctrl+f 搜索该网页的内容。

同样的概念也适用于 Access 应用程序。询问要处理什么，然后使用“where”子句启动绑定到表的表单的设计将解决此问题。

因此，如果您有一个显示客户发票的表单（甚至是子表单），您将首先询问发票编号，然后使用将表单限制为一张发票的 where 子句简单地启动该表单！

请记住，您仍然可以使用绑定到包含 100 万行的表的发票表单，并且只有一条记录将被拉下网络连接 *如果使用where 子句.

因此，典型的互联网连接具有足够的速度来运行浏览器，并且还具有足够的带宽速度来下载一些记录。 Access 经常因性能不佳而受到批评，但这只是因为 Access 开发人员忽略了一个明显的建议，即将大量不需要的内容下载到表单中会运行缓慢。

因此，基于 Web 的应用程序，甚至是用 vb.net 编写的桌面应用程序在云端运行的 SQL Azure 上运行良好，但互联网连接速度要慢得多，因为这些应用程序不会启动绑定到大型数据集的表单，而无需首先简单地允许用户请求他们需要查看和查看的内容。

对于 Access 和使用 SharePoint？该设置可以非常快，实际上比 SQL Azure、mysql 或任何传统数据库系统快得多，因为当您使用 SharePoint 表和 Access 时，Access 会自动同步本地数据的副本。此设置意味着您的应用程序将在没有任何 Internet 连接的情况下继续运行。一旦连接恢复，数据同步就可以恢复。

这意味着，如果您有一个包含 15,000 行的表并针对该数据运行报告，则该报告可以通过 SharePoint 后端立即运行和启动，因为数据的本地副本始终存在于前端！因此，此设置非常适合离线模式，或者在您的互联网连接较差且速度较慢的情况下，因为如上所述，您始终拥有数据的本地副本 - 只有在更改记录时才会发生同步，并且同步可以发生独立于访问。因此，您更改了一条记录，它开始与 SharePoint 同步。

但是，对于必须更新的较大数据集，SQL Server 要好得多，因为您可以在 10,000 行上执行 sql 更新，并且在使用 SQL Server 时需要发生零网络流量和数据传输来更新这 10,000 行（传递查询），并且在使用 SharePoint 时，这 10,000 行将通过网络传输，因为本地副本需要更新行。因此，对于必须更新大量行或执行大量行更新类型的数据处理的应用程序，不存在将 SharePoint 用于数据库后端的巨大优势。

所以这里的关键概念和要点：

您拥有的高速互联网连接通常比典型的廉价办公室（本地）网络慢 10-200 倍。因此，这意味着 2 秒的操作现在将花费 10-200 倍的时间。

需要优化 Access 应用程序以避免将太多记录加载到表单中。因此，构建搜索表单等。首先询问用户他们需要做什么是所有优秀开发人员（包括 Access 开发人员）的基本且简单的要求。

Access 和 SharePoint 可能是最佳选择，这样的设置允许应用程序在完全没有互联网连接的情况下运行。如果表大小低于 10,000 行，那么这种设置通常是理想的。但是，对于必须更新大量行的应用程序和数据处理繁重的应用程序，此设置很差，因为对任何行的更新都会导致数据同步通过网络发生。这种设置也是最便宜的，因为一个带有 SharePoint 支持 Access 的 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 后端。这里有一个很大的警告，因为只有某些类型的应用程序才能很好地与 SharePoint 表配合使用。对我来说，解释这些应用程序为什么、如何以及何时更好，这不仅仅是一篇简单的文章，但需要注意的是，SharePoint 可以是令人难以置信的解决方案，但并非适用于所有应用程序，SQL Server 可以并且将会是更好的选择.这种 SharePoint“更好”的选择只能根据给定类型的相关应用程序的个案评估来确定。

【讨论】：

这篇文章中可能隐藏了一些有价值的信息，但耶稣。什么鬼？

我重新编辑了。只是想确保注意到这里超出疯狂的建议并因此被忽略，除非每个人都喜欢这里的愚蠢。

谢谢你，@Albert

可能是最好的解释（详细、有趣、易于理解）我会投票 10 次

这个答案有助于让人们思考应用程序和数据库之间的连接，但不幸的是，它没有讨论往返时间，这通常会产生更大的影响。例如，如果您的代码在一次调用中要求 10k 条记录，则在从数据库 200 毫秒时它不会明显变慢，但如果它进行 10k 次调用（往返）来获取这些记录，那么一轮将需要 33 分钟行程时间。

【参考方案2】：

问题只是 Azure SQL 数据库 与例如内部 SQL 实例相比，使用小型 DTU（数据库事务单元） 运行速度不是很快服务器托管在即使是中型现代服务器上。

我也检查过它，它需要对查询和过滤进行极其仔细的设计——这与您通常可以逃脱的事情相去甚远——以获得可接受的整体速度。另一方面，这是一种给予的体验，它将把注意力集中在你可能不会遇到的潜在瓶颈上，否则可能为时已晚。

【讨论】：

迁移到 MySQL 后，访问前端的运行速度几乎与我在本地网络上的运行速度相同。

【参考方案3】：

好的，所以经过将近一周的尝试让这个工作（访问前端到 Azure 上的 SQL Server 后端），我得出结论，这不是一个可行的解决方案。

我尝试了 SQL Server，并在 Azure 上设置了 Sharepoint 2016 服务器，但也失败了。

有效的方法是使用 Bullzipp 的一款名为 MS Access 的产品来转换访问表，然后在服务器上添加一个 MySQL DB 并导入 Bullzip 生成的文件。这里唯一要注意的是 Bullzip 不喜欢较新的访问格式（它需要一个 MDB 文件），所以转到 Access，创建一个新的空文件，但确保将其文件类型设置为 MDB。然后导入您的表格并运行 Bullzip。

它现在的运行速度比 SQL Server 快得多，但我在 Access 中遇到了一些写入冲突，所以我只需要检查代码并做任何我需要做的事情，这样我就可以避免这些消息。

【参考方案4】：

使用 Access 作为 Azure SQL 表的前端是最糟糕的解决方案。但是，有时你必须这样做。我有一个客户坚持要保留她的 Access 数据库。当她雇用她的第一个员工时，很明显她需要在屏幕后面对表进行 SQL 处理。

这简直是一场噩梦。然而，在重新设计了一些糟糕的表结构、创建视图和许多过程之后，我已经能够做到了。在某些情况下，我使用本地表，并通过从存储的过程中提取并插入本地表来重新填充。我使用链接表进行基本数据编辑，并且几乎不断地进行显式保存记录。

我还有一个首次加载模块，它打开所有表单，转到最后一条记录，返回第一条记录，然后在需要时隐藏表单。负载跛行大约 3

我现在唯一剩下的问题是，Azure 将在（我认为）30 分钟或更长时间的空闲时间后关闭连接——或者可能是笔记本电脑休眠的时候？这会杀死应用程序，必须将其关闭并重新打开。

【讨论】：

这没有提供问题的答案。一旦你有足够的reputation，你就可以comment on any post；相反，provide answers that don't require clarification from the asker。 - From Review