表访问的性能答案

【问题标题】：Performance of table access表访问的性能
【发布时间】：2009-12-07 09:27:10
【问题描述】：

我们有一个完全用 C 语言编写的应用程序。对于代码中的表访问，例如从表中获取一些值，我们使用 Pro*C。为了提高应用程序的性能，我们还预加载了一些用于获取数据的表。我们通常会获取一些输入字段并从表中获取输出字段。

我们通常在表中有大约 30000 个条目，有时最多达到 10 万个。

但是如果表条目增加到大约 1000 万个条目，我认为它会危险地影响应用程序的性能。

我是不是哪里错了？如果真的影响性能，有什么办法可以让应用的性能保持稳定？

考虑到应用程序处理表的方式，如果表中的行数增加到 1000 万，可能的解决方法是什么？

【问题讨论】：

真正的问题是什么？你的问题真的很难理解。否则，您的问题的答案是“除非您使用分析器，否则无法判断”。
“10万”在印度英语中是 100.000
您正在将 1000 万行从数据库复制到应用程序内存中？假设您需要数据进行单行查找，您确定您的代码比 Oracle 的代码快吗？始终使用 SQL 语句。哦……性能很关键？？？如果您的程序使用您的代码需要 0.03 毫秒，而使用 Oracle 代码需要 3 毫秒（100 倍以上），谁会注意到？
接下来的问题是“如何在包含 30000 到 1000 万个元素的表格上提高搜索时间？”
为什么要在应用中缓存 Oracle 表数据？ Oracle 可以做得很好，而且在许多情况下比您的应用程序更好。当然，如果合适的话，您可以配置 Oracle 以将整个表加载到内存中。让数据库引擎处理数据。

【解决方案1】：

如果您不对表格进行排序，您的搜索时间会成比例地增加...如果您没有编码任何错误，在您的示例中（30K 与 1M），您将获得 33 倍的搜索时间。我假设您正在增量迭代（i++ 样式）表。

但是，如果可以对表格进行排序，则可以大大减少搜索时间。这是可能的，因为搜索已排序信息的索引器算法不会解析每个元素，直到它到达寻找的元素：它使用辅助表（树、哈希等），通常搜索速度要快得多，然后精确定位正确的寻找元素，或者至少可以更准确地估计它在主表中的位置。

当然，这将以必须对表进行排序为代价，无论是在其中插入或删除元素时，还是在执行搜索时。

【讨论】：

如果所有 1000 万个条目都将被预加载到内存中。它会将 7GB 的数据加载到内存中，我认为它不起作用
所以这是两个不同的问题：内存和搜索时间。如果这是磁盘上的大量数据（以这种方式接缝，但请纠正我），那么通过将其加载到内存中您不会获得任何东西（它将由操作系统进行页面归档）。也许您需要构建一个适合更快搜索的哈希表（取决于您的标准），并带有指向磁盘上数据的指针？

【解决方案2】：

也许你可以去'google hash'看看他们的实现？虽然它是在 C++ 中

【讨论】：

【解决方案3】：

一旦增加超过 1MB 或无论您的缓存大小是多少，您可能有太多的缓存未命中。

如果您多次迭代表或随机访问元素，您也可能会遇到很多缓存未命中。

【讨论】：

【解决方案4】：

嗯，这实际上取决于您对数据的处理方式。如果您必须将整个 kit-and-kabootle 加载到内存中，那么合理的方法是使用较大的块大小，这样需要发生的 oracle 往返次数就很少。

如果您没有真正的内存资源来允许将整个结果集加载到内存中，那么较大的批量大小仍然有助于减少 Oracle 开销。将合理大小的记录块放入内存，对其进行处理，然后获取下一个块。

如果没有关于您的实际运行时环境和业务目标的更多信息，这几乎是任何人都可以获得的具体信息。

你能告诉我们更多关于这个问题的信息吗？

【讨论】：