MySQL 索引长度解释

Question

查看以下 3 个 MySQL 表的索引长度是否通常比实际行数高得多？

在开始快速降低性能之前，索引的长度是否有限制，例如第一个索引长度为 2.06 亿以上的表？

table_rows  data_length index_length    Size in MB
7607749     5044389164  206542848       5007.68
3110749     1832710212  793864192       2504.9
4811507     1088374128  318001152       1341.22

Answer 1

table_rows是表中的行数。这个数字对于 MyISAM 来说是准确的，但对于 InnoDB 来说只是近似值。 data_length是表的数据部分中的字节数。对于 InnoDB，这包括PRIMARY KEY. index_length是索引的字节数（不是行数）（如果 InnoDB 不包括 PK）。

如果您有大量索引，index_length 可以大于 data_length。这是您可能有太多索引的线索，但这不一定是“坏的”。

每个索引都存储为一个独立的 BTree。当你添加另一个索引时，你会得到另一个 BTree；这并不会影响现有的索引的性能。

你的表有几百万行；这意味着每个 BTree 大约有 4 层深。如果表增长到 10 亿行，它的 BTree 将增长到大约 5 个级别。这是次要的。

当事情变大时，就会发生退化。但事情并没有那么简单。

示例 1：您的数据具有日期时间索引或 auto_increment PRIMARY KEY，并且您始终只查看“最近”行。在这种情况下，“工作集”可能足够小以适合 RAM。随着数据和索引的增长，您不会注意到任何性能下降。

示例 2：某些查询需要扫描整个表或整个索引。这会导致缓存耗尽，性能下降。

示例 3：UUID 上的索引。这是一个非常随机的索引。您插入或选择的“下一个”UUID 与您最近接触过的其他 UUID 没有关系。因此，一旦数据/索引对于 RAM 来说太大，您可能需要访问磁盘。在这里，性能逐渐变差。

我的观点是性能下降是数据/索引大小、访问模式、缓存大小和 RAM 大小的组合。不仅仅是您正在查看的数字。