访问本地前端连接到Azure SQL Server后端很慢

Question

我一直在使用Access来快速原型数据库。现在我想进行一个小组在线测试，因此我拆分了数据库并将后端放置在Azure SQL Server上，然后重新链接。这是非常缓慢的，我一直在研究解决方案的日子没有积极的结果。我的本地环境是Win10，Office2016 64位和互联网连接快速和稳定。

我试过不同的ODBC驱动程序，包括SQL Native Client v11。

我已禁用NIC上的自整定级别。

我重新创建了服务器上访问的所有查询。

我已确认在ODBC中的跟踪已关闭。

但我启用了跟踪暂时看看发生了什么。如果我打开前端，登录（小用户表），并在第一个表单上做了一些操作（添加1个记录和3个子记录......并且真的......没有任何花哨或沉重的东西，而这只需要1分钟）然后关闭数据库，我发现跟踪日志文件是1.5MB。

所以我创建了一个空Access文件和ODBC连接到只有用户表（12列，20条），然后再次监测跟踪日志文件。打开访问不会向日志文件添加任何内容，但打开这个链接表后，日志文件将增长到255kb。在访问中打开此表需要5秒钟。

访问发送了大约800个请求到服务器打开这个小表。如果我将所有用户表格数据粘贴到文本文件中，则只有2kb。 SO为什么这么慢？

对此有任何想法，特别是其他建议，以更快地工作？

亲切的问候，

Answer 1

好了，经过将近试图得到这个工作（Access前端到SQL Server Azure上的后端）一个星期，我得出的结论是，它不是一个可行的解决方案。

我试过SQL Server和安装在Azure上一个SharePoint 2016服务器，这也失败了。

有什么使用的产品从Bullzipp称为MS访问MySQL转换的访问表，然后在服务器上添加一个MySQL数据库和导入通过的BullZip生成的文件工作。这里唯一要注意的是，Bullzip不喜欢较新的访问格式（它想要一个MDB文件），所以去访问，创建一个新的空文件，但确保您将其文件类型设置为MDB。然后导入您的表并运行Bullzip。

它现在比SQL Server工作速度快很多，但我在Access中遇到了一些写入冲突，所以我只需要通过代码并执行所需的任何操作，以便我可以避免这些消息。

Answer 2

的问题很简单，Azure的SQL数据库是不是非常快的小的DTU（数据库事务单位）运行相比，比方说，SQL Server的内部实例承载的能力，即使温和的现代服务器。

我检查出来过，它需要查询和过滤的非常细心的设计 - 远离你通常可以逃脱 - 获得可接受的整体速度。另一方面，这是一种给予体验，它将注意力集中到潜在的瓶颈上，否则它可能为时已晚。

Answer 3

那么，使用Azure的原因比运行Access的速度慢的原因是，连接到本地SQL Server实例的原因是，速度慢很慢！

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

因此，这里是你需要知道的问题：

为什么走路比开车慢？

回答，因为您的旅行速度较慢！

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

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

这里的想法，你不会考虑连接速度的差异是这里的问题。对于公众来说，这可能会导致这样的设置（访问SQL Server的Azure实例上的前端）不是一个可行的设置。

因此，这里的第一个问题是记录到后端数据库的连接速度。

典型的办公室局域网的速度为100MBits，或者今天大多数是1gig--即使是在Best Buy购买的el-cheapo路由器现在的额定容量为1gig（1000 mbits）。

但是，您的典型高速互联网的额定值为5或10兆位。所以这是100倍慢。 （其实1000/5 = 200倍慢!!!）。

这意味着如果您的办公网络需要3秒钟的时间与Access和SQL服务器？那么一个广域网（通过互联网），那么你需要通过改变连接速度来增加时间（这很简单 - 但它似乎逃脱了所有！）。所以，如果你幸运的话，你的网络速度可能会达到5Mbit。这意味着你去

五分之一千= 200

现在你把你的200和多个现有的延时说3秒钟，你会得到600秒（即10分钟，如果你想知道！）。所以你从3秒到10分钟！

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

您绝对可以使用Access到Azure，但您必须实现两个简单的概念。

1 - 连接和测试的连接速度比您的局域网慢50-200倍，这样的测试速度会慢50到200倍！没有提到并考虑到LAN与LAN的速度连接的巨大差异，这是一个简单的问题。

2 - 打开绑定到大型数据表的表单会导致大小写性能问题。

我坐在公交车站跟一位90岁的老太太说话。我问她以下几点：

你有没有使用过即时出纳员？她说，为什么是，我一直都在使用它们。

然后我问这个问题你不觉得在你等待的时候让出纳机下载所有的人的账户是不好的，那么请问你的账号？

这位老太太说，当然这很愚蠢。我输入我的帐户密码，机器只下载我的帐户信息 - 这是实用而明显的。

换句话说，老太太意识到下载一堆数据之前，用户甚至输入或做任何事情都是浪费带宽。

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

即使使用Google，它也不会将整个互联网下载到您的网页浏览器页面，然后按ctrl-f搜索该网页的内容。

相同的概念应该适用于Access应用程序。一个设计，要求什么工作，然后启动一个表格绑定到一个“where”子句将解决这个问题。

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

请记住，你仍然可以使用绑定到1万行，只有一个记录一个表，发票形式将被拉低网络连接*如果一个使用的“where”子句。

因此，一个典型的互联网连接有足够的速度来运行浏览器，也有足够的带宽速度来拉下几个记录。访问通常会导致糟糕的性能表现，但这对于Access开发人员来说只是一个必然的结果，因为忽略了一个明显的建议，即将不需要的大量内容下载到表单中的操作将会很慢。

所以基于Web的应用，或写在vb.net甚至桌面应用程序与SQL Azure在云中过那么多的互联网连接较慢运行，因为这些应用程序不启动绑定到大型数据集不先简单地允许形式表现良好用户请求他们需要查看和查看的内容。

至于访问和使用SharePoint？该设置可以非常快，实际上比SQL Azure，MySQL或任何传统数据库系统快得多，因为当您使用SharePoint表和Access时，Access会自动同步数据本地副本。此设置意味着您的应用程序将继续运行，而无需任何互联网连接。即时连接恢复，然后数据同步可以恢复。

这意味着如果您有一个包含15,000行的表并运行有关该数据的报表，则该报表可以在SharePoint后端立即运行并立即启动，因为数据的本地副本位于ALL TEST的前端！所以这个设置非常适合脱机模式，或者你的互联网连接速度很慢并且速度很慢，因为你提到的数据总是有本地数据副本 - 只有当记录被改变时才会发生同步，并且该同步可以独立于Access而发生。因此，您更改了一条记录 - 并开始与SharePoint同步。

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

所以关键概念，并带走这里：

的你有高速互联网连接往往比典型的廉价办公室（本地）网络慢10-200倍。这意味着2秒的操作现在需要10-200倍的时间。

Access应用程序需要进行优化，以避免将太多记录加载到表单中。因此构建搜索表单等等。首先要问用户他们需要处理的是对所有优秀开发人员以及包括Access开发人员的基本和简单要求。

访问和SharePoint可以是最好的选择，并且这样的设置允许应用程序甚至在没有互联网连接时运行。如果表格大小低于10,000行，那么这种设置通常是理想的。然而，对于必须更新大量行和处理大量数据的应用程序，此设置很差，因为对任何行的更新都会导致数据同步通过网络发生。此设置也是最便宜的，因为具有SharePoint支持Access的单个Office 365帐户每月可以支付6美元，而6美元帐户最多允许500个免费用户，而这500位用户甚至可以使用他们的Gmail或非Microsoft帐户为此设置。而且，这种适合SharePoint表格边界的访问应用程序往往需要更少的更改和优化，然后通过Internet使用SQL Server。

使用SQL服务器，使用视图，pass-tough查询以及在某些情况下编写存储过程允许更新和代码在不使用任何带宽的情况下运行。因此，可以将单个更新查询发送到更新10,000行数据的服务器 - 唯一的网络成本将是发送该sql语句的“微小”带宽量。

因此，尽管绑定表单可以与运行在云中的SQL Azure一起使用，但需要构建类似于Web的软件或vb.net，在这些软件中，他们首先询问用户要使用哪个帐户或客户，然后启动UI以显示给定的数据。

所以在访问中，将构建一个搜索表单这样说：

在一天结束

所以，在这里忽略职位，表明访问云to SQL是很重要不可行。使用适当的设计进行访问将比在Azure上运行的SQL服务器的典型互联网连接工作得更好。

事实上，我看到有人在56k调制解调器上使用Access to SQL！

必须采用合理的设计，其中为特定任务提取的数据受到限制 - 这是所有开发人员的大厅标记 - 唯一的问题是Access不执行此方法，而大多数其他开发人员工具不允许你把自己挂在大桌子上的装订形式！这并不是说访问速度很慢，但是当您做出糟糕的设计决策时访问速度很慢。

对SharePoint的访问可能是一个真正的赢家 - 尤其是对于带宽不足，带宽不稳定的情况，甚至当连接丢失时，如果运行相同的应用程序，应用程序将继续运行并且运行速度超过99％与SQL后端。这里有一个大的警告，因为只有某些类型的应用程序可以很好地处理SharePoint表。我解释了为什么，怎么样，当这样的应用更好地超出了一个简单的帖子在这里，但人们只需知道的SharePoint可不得了的解决方案，而不是对所有的应用程序和SQL服务器能够而且将会是更好的选择。这种SharePoint“更好”的选择只能根据特定类型的应用程序的案例评估来确定。