我们使用 Access 数据库作为我们软件产品的后端。该程序已经在一家公司进行了大约 2 年的 alpha/beta 测试，我们注意到我们的一个表在那段时间里已经填满了超过十万条记录。这可能不是我们的产品将承受的最频繁使用的例子，我们担心 future 5-10 年的性能。
我们有一种合乎逻辑的方法可以将这个巨大的表分解成包含数百条记录的数千个表，但我认为这种解决方案可能不会帮助解决任何可能的减速问题，因为数据库会因表而变得臃肿数据(虽然我没有接受过正式的数据库培训，所以我知道什么)。
我希望有人比我更了解我们是否可能会看到明显的放缓，如果是这样，哪种解决方案可能会长期保持更好的性能？
最佳答案
数据库通常经过优化以处理大量行；问题是，您能否维护数千张几乎相同的表？ (很少有人可以，用它编码很复杂)
首先，测试可能的场景。我不熟悉你的数据，所以我不能告诉你数百万行对于数据库来说是否太多(毕竟，这是 MS Access，不是真正的数据库)。
如果发现您的表大小有问题，并且您的数据集可以分为较少使用的(较旧的？)和最近的数据，我建议将表分成两部分:table 和 table_archived(其中包含较少使用的/较旧的记录)。这可能是表大小和可管理性之间的合理折衷。
关于database - 哪个更影响 Access 数据库性能 : Thousands of tables or Millions of records?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3294135/