3

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

我进行了一些测试（并得到了一些相当令人惊讶的结果，特别是在使用顺序GUID 时从 SQL Server 获得的结果：插入性能下降得非常快，而且对我来说这么快下降似乎并不合适。

基本上测试如下：

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

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

一些结果（更多，在我关于测试的博客条目中提供了原始数据）：

很明显，随着数据库的增长，插入性能会降低，但 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

我发现我的服务器配置有问题，我更新了我博客上的测试。
感谢大家的回复，他们对我帮助很大。

4

5 回答 5

4

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

相比之下，Access 被设计为在大多数用例中运行良好，无需任何配置。第二点涵盖了这种权衡的缺点：

SQL Server 专为可伸缩性而设计。请注意只有 100,000 条记录，Access 是如何严重降级的。在一百万之前，它可能会急剧下降到 SQL 的线以下。相比之下，SQL Server 几乎保持完全稳定，在大约 45,000 条记录之后变化趋于稳定，并将继续保持数百万。

编辑我认为这里可能还有其他我们没有看到的东西在起作用。我认为您的 SQL 编号看起来很糟糕，所以我自己进行了测试。在我的运行 Windows Vista 3.6 ghz 和 2gb RAM 的桌面上，在 SQL Server 上执行具有顺序 GUID 的插入：

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

  • 在 500k 条记录下，平均每秒插入 1426 次

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

因此，考虑到在使用中的桌面上运行它所产生的正常差异，我会说 SQL Server 插入基本上从 0 条记录线性扩展到半百万。在专用的、经过调优的服务器上，我希望获得更高的一致性（更不用说更好的性能了）：

Excel 图表，每秒插入次数 http://img24.imageshack.us/img24/9485/insertspersecond.jpg

于 2009-04-09T02:10:45.000 回答
2

您意识到性能下降的至少部分原因是日志被填满，而 GUID id 比 int 长 40 个字节？

但我不是在狡辩；很高兴看到有人采用实际指标，而不仅仅是挥手。修改了。

于 2009-04-09T02:09:48.513 回答
2

你从哪里得到数据？

如果您使用 Access Export 菜单选项而不是每次循环记录，它会更改数字吗？

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

如果标识列是可接受的，为什么还要考虑顺序 GUID（这是我上次检查的 MSSQL 中的一种附加功能）。

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

于 2009-04-09T03:05:11.313 回答
2

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

您的应用程序会一次添加大量记录吗？

还是会根据 SQL SELECT 追加成批的记录？

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

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

最后，就在上周，有人让我注意到了 Andy Baron 的这篇引人入胜的文章：

优化链接到 SQL Server 的 Microsoft Office Access 应用程序

我仍在吸收那篇非常有用的文章的内容，它讨论了与非 GUID 特定主题有关的几个问题，这些问题可以帮助您优化流程以获得最大效率。

于 2009-04-09T22:21:54.737 回答
1

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

另外，只是想一想，是否涉及任何交易？也许 SQL Server 事务会产生访问所没有的巨大性能影响（鉴于访问并非真正面向并发访问）。

于 2009-04-09T03:26:54.507 回答