我们有一个针对公司服务器上的访问数据库编写的 Windows MFC 应用程序。数据库不是那么大：19 MB。任何时候最多有 2-3 个用户访问它。它用于工厂环境中，因为它是我们小部件制造时间的一部分，因此通过 Intranet 的访问速度（或缺乏访问速度）变得很明显。
场景是这样的：随着每个小部件完成，它会在数据库中获取一条记录。到年底，数据库更大，搜索记录的时间越来越长。迄今为止的解决方案是大约每年一次将旧记录手动移动到存档表中。
我们现在正在修改这个应用程序的其他部分，如果我们打算这样做的话，现在是转移到另一个数据库的好时机。
据我了解，如果我们使用 sql，搜索时间不会随着表变大而增加，因为不必每次都通过网络发送整个 .mdb。它是否正确？有没有人知道是否值得去麻烦（时间和金钱）迁移到新数据库，或者我应该为我们现在拥有的应用程序添加更多功能，并且可能自动清除旧记录不时，并在需要时向应用程序添加额外的功能以获取较旧的记录？
感谢您可以分享的任何智慧..
由于您的数据库很小且用户很少，因此我无法为迁移提供可靠的理由。我会明确地设置一个脚本来更频繁地归档旧记录（不要归档到同一个数据库中，这会有点违背目的）。但也要确保两件事也是正确的。
将先进技术用于简单问题是一种昂贵的方法，但并不总是答案！
首先，整个表和整个数据库通过网络传输的信息根本是不正确的。如果查询已编入索引，则搜索时间不应随着时间的推移而增加太多。
正如其他人提到的那样，花费时间和金钱来设置和维护，然后让某人维护、管理和支持该数据库服务器，这当然是一种可能性。但是，请记住，在许多情况下，简单地将基于 JET 的应用程序迁移到 sql server 会运行得更慢，事实上，当不涉及网络时，sql server 会比 JET 慢。
所以，我会花一些时间来确定为什么事情会这么慢，并检查索引是如何设置的。
因此，请记住，整个表和整个数据库都通过网络传输纯属民间传说和神话。这个概念只是因为大多数人真的没有接受过任何计算机培训，也不知道和理解 JET 数据引擎是如何工作的。
如果有资金和时间投入数据访问层，我可能会迁移到 Microsoft SQL Server 2008 R2 Express Edition（免费）或 MySQL（免费）。因为您将向远程服务器发出请求，而不是在本地工作站上对数据进行操作，所以从开发的角度来看，这一举措非常重要。
但是，您应该分析按季度或按月执行归档过程是否更具成本效益，然后将归档数据库移至 SQL Server 2008 R2 Express Edition。（您可以在工作站上安装 Microsoft SQL Server Management Studio 客户端工具并查询存档数据库以更快地报告历史数据，而无需重写整个生产应用程序；使用 MySQL 或其他 OSS/免费 RDBMS 存在类似的解决方案）。
我有 300 mb 数据库的客户，尽管出于其他原因他们应该升级到 SQL Server。19 Mb 相对较小。如果性能太差以至于归档会加快速度，那么请检查所有排序和选择字段的表索引。Albert 给了你一个很好的 URL 来检查。
整个 MDB 文件不会走线。除非您缺少索引。
您可以在服务器上编写一个小包装器来处理请求，在 Access DB 中查找结果（使用 SQL + Access ODBC 驱动程序），然后返回，而不是通过网络将 DB 发送到客户端然后执行查询结果。这避免了您可能不需要的大型迁移的开销，并且仍然摆脱了用户遇到的基本问题。
迁移到“合适的”数据库解决方案是最好的长期解决方案，但如果您的需求在未来 30 年内呈线性且缓慢扩展，则很难证明昂贵的迁移是合理的。也就是说，如果您希望真正提升，或者想要更加“面向未来”，那么现在迁移可能会节省金钱/时间。
据我了解，如果我们使用 sql，搜索时间不会随着表变大而增加，因为不必每次都通过网络发送整个 .mdb。它是否正确？
这个一般想法几乎适用于所有数据库。数据库的想法是将您的应用程序与实际数据分开。数据驻留在数据库服务器中。您的应用程序没有。
有没有人知道是否值得去麻烦（时间和金钱）迁移到新数据库
是的。多次提出这个建议。它的价格昂贵。情况很复杂。您的 MS-Access 数据库永远不会变得更好或更快。
其他数据库服务器将（并且可以）变得更快、更复杂。毕竟，您不再通过网络发送 .MDB 文件。限制减少了。您正在通过 ODBC 使用标准 SQL。任何数据库都将在 ODBC 结束时工作。您可以解雇供应商以寻找更好、更快、更便宜的产品。一旦您停止使用 Access，您就有了选择。
要么立即停止使用 Access，要么计划永远忍受它。并每年重新做出这个决定，直到时间结束。