我正在创建一个应用程序，它必须将最多 32 GB 的数据放入我的数据库中。我正在使用 B-tree 索引，因为读取将具有范围查询（例如 from 0 < time < 1hr）。
一开始（数据库大小 = 0GB），我将获得每毫秒 60 和 70 次写入。在说 5GB 之后，我测试过的三个数据库（H2、berkeley DB、Sybase SQL Anywhere）真的减慢到每毫秒不到 5 次写入。
问题：
笔记：
每条记录由几个整数组成
是的; 索引以插入时间为代价提高了获取时间。你的数字听起来很合理——不知道更多。
您可以对其进行基准测试。您需要存储合理数量的数据。考虑是否根据查询进行索引 - 重获取和轻插入？索引 where 子句可能使用它的任何地方。轻取，重插入？可能避免索引。混合工作量；标杆吧！
在进行基准测试时，您需要尽可能真实或真实的数据，无论是在数量上还是在数据域上（例如，数据的分布，不仅仅是所有的“henry smith”，而是各种名称）。
索引通常会牺牲插入速度来换取访问速度。你可以从一个为每一列建立索引的数据库表中找到它（我已经在野外看到过这些）。如果更新的数量与查询的数量相比很小，那么这并没有本质上的错误。
但是，鉴于：
1/ 您似乎担心您的写入速度会减慢到 5/ms（仍然是 5000/秒），
2/ 每条记录只写几个整数；和
3/您的查询仅基于时间查询，
您可能需要考虑绕过常规数据库并滚动您自己的数据库（我的想法是您正在收集实时数据，例如设备读数）。
如果您只编写按顺序计时的数据，您可以只使用一个平面文件并定期单独写入“索引”信息（比如在每分钟开始时）。
这将大大加快您的写入速度，但仍允许相对有效的读取过程 - 最坏的情况是您必须找到相关时期的开始并从那里进行扫描。
这当然取决于我对您的存储是否正确的假设：
1/ 您正在按时间顺序写入记录。
2/您只需要查询时间范围。
是的，索引通常会减慢插入速度，同时显着加快选择（查询）。
请记住，并非所有对 B 树的插入都是相等的。这是一棵树；如果你所做的只是插入它，它必须不断增长。数据结构允许进行一些填充，但如果您继续向其中插入按顺序增长的数字，则它必须不断添加新页面和/或随机播放以保持平衡。确保您的测试插入分布良好的数字（假设这就是它们在现实生活中的方式），并看看您是否可以做任何事情来告诉 B-tree 从一开始就期望有多少项目。
我认为他们在 BDB 文档的某处提到页面大小极大地影响了 btree 中的这种行为。假设你没有在并发方面做太多事情并且你有固定的记录大小，你应该尝试增加你的页面大小
完全同意@Richard-t - 在离线/批量场景中，在批量更新语料库之前完全删除索引是很常见的，只有在更新完成时才重新应用它们。
应用的索引类型也会影响插入性能 - 例如，对于 SQL Server 聚集索引更新 I/O 用于数据分发和索引更新，其中非聚集索引在单独的（因此更昂贵的）I/O 操作中更新.
与任何工程项目一样 - 最好的建议是使用真实数据集（倾斜页面分布、撕裂等）进行测量