数据库大小如何影响性能：理论与现实

Question

有很多人说数据库大小不应在很大程度上影响性能。只要表上的索引适合内存，数据库就应该保持高性能。

然而事实又是怎样呢？如果数据库架构不是最好的，索引不适合内存，并且可能存在大量冗余数据，是否可以通过删除冗余数据来获得显着收益？我估计我的数据库中 60-80% 的数据可能会被删除。

我相信减少数据库大小并增加 RAM 以便索引可以适应内存会显着提高性能，这将为重新构建系统提供几个月的喘息空间。

是否还有其他因素（例如 IO、碎片、工作数据集等）会根据数据库大小影响性能？

Answer 1

这完全取决于您对数据的处理方式。

对于只影响几行的基本插入/更新/删除事务，那么数据大小的增长可能不是一个大的考虑因素。数据库将使用内存索引来访问正确的页面。当表不再适合内存时，您会遇到更多缓存未命中。但是，开销可能很小——取决于数据库、数据库配置和硬件配置。

如果您正在执行需要全表扫描的查询，那么您的性能将随着数据大小呈线性增长或更糟。通过随机化页面访问，索引实际上会使情况变得更糟，这几乎可以保证缓存未命中。

更多内存的替代方案是提高磁盘速度——固态磁盘可以提供巨大的改进。

除非在查询中使用这些表，否则仅仅拥有更多数据不太可能影响性能。数据是在表内还是跨表冗余？拥有从未使用过的大表很麻烦，但对性能的影响很小。可以想象，如果您有无数个不必要的表，那么编译查询可能会开始花费更多时间。

Answer 2

第一个调整规则 AMM（添加更多内存）很简单。它也是一种成本非常高并且最终在选择性存在问题时无效的方法。即使数据库完全适合内存，应用程序的性能也可能很差。在最坏的情况下，由于在非常选择性的 SQL 执行期间进行锁定和闩锁。这些应该首先解决。原因之一是并发性，如果每个 SQL 每次都访问表中的所有数据，就相当于点击并保持中断。

确保没有 SQL 访问的行数超过所需的行数。这是保持良好绩效的最有效方法。普通数据库知道如何处理 io 并对最常用的数据进行某种形式的缓存。

如果您的应用程序已经最大限度地减少了所有可能的访问，并且您已经使用了最快的磁盘系统，请考虑使用真正的闪存阵列。他们可以将性能提升到另一个水平。