SQL Server与Access的插入性能，特别是在使用GUID时

Question

我很想知道在使用Access 2007作为SQL Server 2008的前端时使用顺序GUID时如何提高SQL Server的性能（请注意它是我唯一感兴趣的上下文）。

我已经做了一些测试（并且得到了一些相当令人惊讶的结果，特别是在使用顺序 GUID时来自SQL Server：插入性能非常快地降低，因此降级似乎不正确很快就对我说。

基本上测试如下：

  

从Access前端，仅使用VBA，以1000个批量插入100,000条记录，   顺序。

• 我尝试使用Identity和顺序GUID作为PK。
• 我在 SQL Server 2008 Standard （没有特别调整只是默认安装）和Access 2007数据库作为后端进行了尝试。所有表都链接回前端。

部分结果（更多，my blog entry about the test上提供原始数据）：

很明显，随着数据库的增长，插入性能会降低，但SQL Server在这里的表现并不是很好。

http://blog.nkadesign.com/wp-content/uploads/2009/04/chart02.png

SQL Server结果的扩展视图： http://blog.nkadesign.com/wp-content/uploads/2009/04/chart03.png

编辑13APR2009

我找到了issue with my server configuration并更新了tests on my blog 感谢所有回复，他们给了我很多帮助。

Answer 1

这里有两件事情可做。首先，重要的是要指出SQL并不一定能很好地工作，对于特定的用例，开箱即用。它是一种专业产品，旨在由知道自己正在做什么的人进行调整。

相比之下，Access可以在没有任何配置的情况下很好地适用于大多数用例。第二点涵盖了这种权衡的缺点：

SQL Server旨在实现可伸缩性。请注意Access如何仅使用100,000条记录严重降级。在百万之前，它可能会在SQL的线之下急剧下降。相比之下，SQL服务器保持几乎完全稳定，在大约45,000条记录之后变化稳定并且将继续保持数百万。

编辑我认为这里还有其他一些东西我们没有看到。我认为你的SQL数字看起来很糟糕，所以我对自己进行了测试。在运行Windows Vista 3.6 ghz和2 GB RAM的桌面上，在SQL Server上执行了带有顺序GUID的插入：

• 0记录每秒平均1382次插入

• 500k记录的平均每秒1426次插入

• 平均每秒1609.6次插入，从0到500k，平均底面为992次插入/秒，平均上限为1989次插入/秒。

因此，考虑到在正在使用的桌面上运行此操作所产生的正常差异，我会说SQL Server插入基本上从0记录线性扩展到50万。在专用的调优服务器上，我期望更高的一致性（更不用说远更好的性能）：

Excel chart, inserts per second http://img24.imageshack.us/img24/9485/insertspersecond.jpg

Answer 2

你意识到至少部分性能下降是日志填满，并且GUID id是什么，比int长40个字节？

但我不是在狡辩;很高兴看到有人采取实际指标而不仅仅是手工操作。修改过。

Answer 3

您从哪里获取数据？

如果您使用“访问导出”菜单选项而不是一次循环记录，是否会更改数字？

VBA对连接参数也非常敏感，而且有很多选项不一定直观。

如果一个标识列是可以接受的，为什么你甚至考虑一个顺序GUID（这是我最后检查过的MSSQL中的一个固定设施）。

<小时/> 编辑： 查看您的代码并简要回顾MSDN上的Recordset文档，我发现您可以使用更高效的参数。例如。您的dbSeeChanges和dbOpenDynaset，如果您尝试允许其他用户弄乱相同的行（或者需要取回插入的IDENTITY值或可能是GUID），这是合适的，但我认为您不需要这些。本质上，在每次INSERT或UPDATE之后，您将从数据库中读回记录到VBA中。我仔细阅读了这些连接配置设置，我打赌你会得到更令人满意的东西。

Answer 4

我的问题是您的测试设置是否代表了您的应用程序的实际情况。简而言之，你正在测试正确的东西吗？

您的应用是否会一次追加大量记录？

或者它是否会基于SQL SELECT附加批量记录？

如果是后者，您可能会尝试在服务器端尝试执行此操作，特别是如果SELECT中的源表位于服务器上。重要的是要意识到，使用ODBC，批处理附加将作为每个行的单个插入发送到SQL Server（每个类都与测试代码中基于记录集的方法类似）。如果您完全在服务器端移动相同的进程，则可以作为批处理操作完成。

此外，您应该使用ADO而不是DAO再次测试。它可以完全不同地优化操作。

最后，有人在上周引起了我的注意，这是Andy Baron撰写的这篇引人入胜的文章：

Optimizing Microsoft Office Access Applications Linked to SQL Server

我仍在吸收这篇非常有用的文章的内容，并讨论了有关非GUID特定主题的几个问题，可以帮助您优化流程以实现最高效率。

Answer 5

我最后一次看到类似的东西（GUID PK真的很慢插入）是因为日志文件填满了。插入性能像石头一样下降，非常快（没有硬测量，只看实时痕迹，但它看起来确实有点像对数）。这是预加载历史数据。 转移到身份PK，负责实际清理日志文件，之后一切都变得更好（几个小时，第一个版本花了几个小时，但没有完成）。

另外，只是想一想，是否涉及任何交易？也许SQL Server事务会创建一个访问权限很大的性能损失（假设访问不是真正面向并发访问）。