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

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

你的应用程序会一次附加大量的记录吗?

或者它是要基于SQL select追加一批记录?

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

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

最后,就在上周,有人让我注意到安迪·巴伦的这篇迷人的文章:

Optimizing Microsoft Office Access Applications Linked to SQL Server

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

这里有两件事要做。首先,重要的是要指出,对于特定的用例,开箱即用,SQL不一定工作得很好。这是一个专业的产品,旨在由一个人谁知道他们在做什么。

相比之下,访问被设计为在大多数没有任何配置的用例中都能很好地工作。第二点涉及了这种权衡的负面影响:

SQL Server是为可伸缩性而设计的。请注意,只有100000条记录,访问会严重降低。它可能会在100万之前大幅下降到SQL的线以下。相比之下,SQL Server保持着几乎完全稳定的状态,在大约45000条记录之后,变化趋于稳定,将继续保持数百万条记录。

编辑 我想这里可能还有一些我们看不到的东西。我觉得你的SQL数字看起来很糟糕,所以我自己做了一个测试。在运行Windows Vista 3.6 GHz和2GB 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

您认识到,性能下降的部分原因是日志被填满,而guid id比int长40个字节?

但我不是在争论;很高兴看到有人拿着实际的指标,而不仅仅是握手。模型化了。

您从哪里获取数据?

如果您使用访问导出菜单选项而不是一次记录一个循环,它是否会更改数字?

vba对连接参数也非常敏感,有很多选项不一定是直观的。

如果一个标识列是可接受的,那么为什么还要考虑一个连续的guid(这是我上次检查的MSSQL中附加的工具)。

上次我看到类似的情况(guid pk的插入速度非常慢)是因为日志文件被填满了。插入性能像石头一样下降,速度非常快(不需要进行严格的测量,只需查看活动痕迹,但看起来确实有点像对数)。这是历史数据的预加载。 转移到Identity PK,处理实际清理日志文件,之后一切都好得多(几个小时后,第一个版本花了几个小时,但还没有完成)。

还有,只是想一想,有没有涉及到交易?也许SQL Server事务会对访问造成巨大的性能冲击(考虑到访问实际上并不面向并发访问)。