我们有一个完全用 C 编写的应用程序。对于代码中的表访问，例如从表中获取一些值，我们使用 Pro*C。为了提高应用程序的性能，我们还预加载了一些用于获取数据的表。通常，我们获取一些输入字段并从表中获取输出字段。
我们通常在表中有大约 30000 个条目，有时最多达到 10 万个。
但是如果表条目增加到大约 1000 万个条目，我认为它会危险地影响应用程序的性能。
我在某个地方错了吗？如果真的影响性能，有没有什么办法可以让应用的性能保持稳定呢？
考虑到应用程序处理表的方式，如果表中的行数增加到 1000 万，可能的解决方法是什么？
也许你可以去'google hash'看看他们的实现？虽然它是 C++
好吧，这实际上取决于您对数据的处理方式。如果您必须将整个 kit-and-kabootle 加载到内存中，那么合理的方法是使用较大的批量大小，以便需要发生的 oracle 往返次数很少。
如果您真的没有内存资源来允许将整个结果集加载到内存中，那么大的批量大小仍然有助于减少 Oracle 开销。将合理大小的记录块放入内存，处理它们，然后获取下一个块。
如果没有关于您的实际运行时环境和业务目标的更多信息，这几乎是任何人都可以获得的具体信息。
你能告诉我们更多关于这个问题的信息吗？
一旦增加超过 1MB 或无论您的缓存大小是多少，您可能有太多的缓存未命中。
如果您多次迭代表或随机访问元素，您也可能会遇到很多缓存未命中。
如果您不对表格进行排序，您将获得成比例的搜索时间增加......如果您没有编码任何错误，在您的示例中（30K 与 1M），您将获得 33 倍的搜索时间。我假设您正在增量迭代（i++ 样式）表。
但是，如果可以对表格进行排序，则可以大大减少搜索时间。这是可能的，因为搜索排序信息的索引器算法不会解析每个元素，直到它到达寻找的元素：它使用辅助表（树、散列等），通常搜索速度更快，然后精确定位正确的寻找元素，或者至少可以更接近地估计它在主表中的位置。
当然，这将以必须对表进行排序为代价，无论是在其中插入或删除元素时，还是在执行搜索时。