访问连接到 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 分钟或更长时间的空闲时间后关闭连接——或者可能是笔记本电脑休眠的时候？ 这会杀死应用程序，必须关闭并重新打开它。