构建 ADO 记录集时是否将数据拉入内存？答案

【问题标题】：Is data pulled into memory when building an ADO Recordset?构建 ADO 记录集时是否将数据拉入内存？
【发布时间】：2011-11-02 12:46:50
【问题描述】：

我一直在从事一个相当大的 C++ 项目，该项目令人惊讶地使用 MS Access 97 作为其底层数据库引擎。我注意到代码中有很多实例是从可能返回超过 100,000 条记录的查询中创建记录集的。

我很好奇 ADO 是否会在您构建记录集时将所有这些数据拉入内存，或者它是否更智能并且只能在您尝试从记录集中读取数据时“及时”加载数据?我们收到了很多来自客户的性能投诉，这让我觉得很内疚。

（迁移到更新的数据库引擎已在我们的路线图中。相信我，团队中没有人对 Access 感到满意）

【问题讨论】：

标签： c++ ms-access ado

【解决方案1】：

这里使用Access数据库有几个问题：

据说支持255个并发用户，实际在6个之间而20是最大数量，作为数据库的连接数较少规模/复杂性增加。
对数据库大小的 2Gb 限制和
是的，数据在本地缓存，所以如果您有 5000 个结果，那么你只需要接受它们:)

【讨论】：

不幸的是，我们非常清楚问题 #1 和 #2（我们的一些特别脾气暴躁的客户也是如此）。但是＃3是我个人不确定但有怀疑的地方。团队急于让管理层重新编写我们的数据库层！
我感受到了你的痛苦！正是由于这些问题，现代实践是结构化代码，使业务逻辑不知道数据源，只是从数据层中检索数据。
同意，不幸的是，这段代码开始于 1997 年，当时 Access97 是新的热点，而 C++98 尚未最终确定！此外，我们的数据层暴露了很多关于 ADO 的实现细节（包括 hacks），这太可怕了。很长一段时间以来，我一直渴望重写我们的整个数据层。感谢您的见解。

【解决方案2】：

我很好奇 ADO 是否会在您构建记录集时将所有数据拉入内存，或者它是否更智能并且只能在您尝试读取数据时“及时”加载数据记录集的？

也许异步获取行可以改善您的用户体验。请参阅ExecuteOptionEnum 中的选项，这些选项可与ADO Recordset Open Method 一起使用。我怀疑这就是您对“及时”的想法，但这是我能提供的最好的。

在我看来，更好的设计是修改查询以仅检索 100K 行的子集。那么“及时”可以变成“让用户请求下一个子集”。并且您应该能够从具有合理大小的记录集的 Access 中获得不错的性能。

【讨论】：

得到一个子集正是我打算做的。我们正在尽快切换到不同的引擎，应该很清楚我们当前的数据层存在缺陷。我的意图是推动整个数据层被重写，这样我们就可以进行适当的“及时”检索。我在构建 Web 应用程序方面的历史要长得多，这就是我们在大型数据库上实现近乎即时的页面加载的方式。目前，我们一直在清理现有层的问题，这让我想知道 ADO 是否真的在您构建记录集时在本地缓存数据。
这不是主题，但似乎我们的数据层试图成为它自己的数据库引擎并管理内存中的所有内容，而不是依靠实际的引擎来担心细节。我可以理解为什么因为底层存储在 Access97 中，但这仍然是一个糟糕的主意~_^
我想知道我们是否可能在这里谈论不同的目的。无论您选择哪种数据库引擎，您的应用程序都应使用大小合理的记录集。如果这些庞大的记录集是客户性能投诉的原因，并且您希望尽快满足客户的需求，请立即修复记录集问题。不要等到切换数据库引擎并重写整个数据层。但首先验证您的假设这些记录集是投诉的原因。复制数据库，转储大部分记录，看看会发生什么。
我完全同意。然而，这个代码库超过 200 万行 C++，其中很大一部分取决于我们的数据层。更改数据层的底层实现将意味着大量的测试覆盖，这将花费我们的测试团队相当多的时间来完成。我们的预算中还没有这个。然而，它将“很快”到来，在那里完全重写是可能的。这个问题过于系统化，无法解决我们目前的预算。我正在向数据层添加一个新区域，所以请放心，新功能会正常工作。
那我就退了。 :-) 如果努力并非不合理，请查看异步获取数据是否会改善用户体验。而且我仍然会验证性能问题是由这些记录集的大小引起的假设......应该很容易测试并且不需要任何 c++ 代码更改。