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

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

但是现实是什么？如果数据库体系结构不是最好的，则索引将无法容纳在内存中，并且可能存在大量冗余数据，是否只需删除冗余数据即可获得显着收益？我估计可以删除数据库中60-80％的数据。

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

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

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

对于仅影响几行的基本插入/更新/删除事务，则数据大小的增长可能不是主要考虑因素。数据库将使用内存中索引来访问正确的页面。当表不再适合内存时，您将获得更多的缓存丢失。但是，开销可能很小，具体取决于数据库，数据库配置和硬件配置。

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

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

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

第一调整规则AMM（添加更多内存）很简单。这也是一种非常昂贵的方法，最后当选择性存在问题时则没有效果。即使数据库完全适合内存，应用程序的性能也可能很差。在最坏的情况下，由于在非常选择性的SQL执行期间会发生锁定和闩锁。这些应该首先修复。原因之一是并发性，就像每个SQL每次访问表中的所有数据一样，击中并保持中断。

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

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

请参阅以下帖子：

• 在性能开始下降之前，MySQL数据库能达到多少？
• 为什么MySQL对于大型表可能会变慢？

使数据尽可能小的提示：

设计表以最小化它们在磁盘上的空间。通过减少写入磁盘和从磁盘读取的数据量，这可以带来巨大的改进。较小的表通常在查询执行期间主动处理其内容时需要较少的主内存。表数据的任何空间减少都会导致索引变小，从而可以更快地处理索引。

MySQL支持许多不同的存储引擎（表类型）和行格式。对于每个表，您可以决定要使用哪种存储和索引方法。为您的应用程序选择适当的表格式可能会大大提高性能。

通过使用此处列出的技术，可以提高表的性能，并最大程度地减少存储空间：-使用可能的最高效（最小）数据类型。MySQL具有许多专门的类型，可以节省磁盘空间和内存。例如，如果可能的话，使用较小的整数类型以获得较小的表。MEDIUMINT通常比INT更好，因为MEDIUMINT列使用的空间要少25％。

• 如果可能，将列声明为NOT NULL。它使一切变得更快，并且每列节省一位。如果您的应用程序中确实需要NULL，则绝对应该使用它。只是要避免默认情况下在所有列上使用它。

• 对于MyISAM表，如果没有任何可变长度的列（VARCHAR，TEXT或BLOB列），则使用固定大小的行格式。

• InnoDB表使用紧凑的存储格式。在5.0.3之前的MySQL版本中，即使对于固定大小的列，InnoDB行也包含一些冗余信息，例如列数和每列的长度。默认情况下，表以紧凑格式（ROW_FORMAT = COMPACT）创建。紧凑行格式的存在将行存储空间减少了约20％，但代价是增加了某些操作的CPU使用率。如果您的工作量是典型的工作量，受缓存命中率和磁盘速度的限制，则可能会更快。如果在极少数情况下受CPU速度的限制，则它可能会变慢。

紧凑的InnoDB格式还更改了存储包含UTF-8数据的CHAR列的方式。如果ROW_FORMAT = REDUNDANT，则假定UTF-8编码字符的最大长度为3个字节，则UTF-8 CHAR（N）占用3×N字节。许多语言主要可以使用单字节UTF-8字符编写，因此固定的存储长度通常会浪费空间。对于ROW_FORMAT = COMPACT格式，InnoDB通过在必要时剥离尾随空格来为这些列分配从N到3×N字节范围内的可变存储量。在典型情况下，最小存储长度保持为N字节，以方便就地更新。

• 表的主索引应尽可能短。这使得识别每一行变得容易而有效

• 仅创建您真正需要的索引。索引对于检索很有用，但是当您需要快速存储数据时就不好了。如果您主要通过搜索列组合来访问表，请在列上创建索引。索引的第一部分应该是最常用的列。如果从表中选择时总是使用许多列，则索引中的第一列应该是重复次数最多的列，以更好地压缩索引。

• 在某些情况下，将经常扫描的表分成两部分可能会有所帮助。如果它是动态格式表，并且可以使用较小的静态格式表（在扫描表时可用于查找相关行），则尤其如此。