看看下面的 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
最佳答案
table_rows 是表中的行数。这个数字对于 MyISAM 是准确的，但对于 InnoDB 来说只是近似值。 data_length 是表数据部分的字节数。对于 InnoDB，这包括 PRIMARY KEY。 index_length 是索引的字节数(不是行数)(如果是 InnoDB，则不包括 PK)。
如果你有大量的索引，index_length 可以大于 data_length。这是一个线索，表明您可能有太多索引，但这不一定是“坏事”。
每个索引都存储为一个独立的 BTree。当你添加另一个索引时，你会得到另一个 BTree；这不会影响现有索引的性能。
您的表有几百万行；这意味着每个 BTree 大约有 4 层深。如果表增长到十亿行，它的 BTree 将增长到大约 5 级。这是次要的。
当事情变大时，就会发生退化。但这并没有那么简单。
示例 1:您的数据具有日期时间索引或 auto_increment PRIMARY KEY，并且您始终只查看“最近”的行。在这种情况下，“工作集”可能足够小以适合 RAM。随着数据和索引的增长，您不会注意到任何性能下降。
示例 2:某些查询需要扫描整个表或整个索引。这会耗尽缓存，性能会一落千丈。
示例 3:UUID 上的索引。这是一个非常随机的索引。您插入或选择的“下一个”UUID 与您最近接触过的其他 UUID 没有任何关系。因此，一旦数据/索引对于 RAM 而言太大，您可能需要访问磁盘。在这里，性能逐渐变差。
我的观点是，性能下降是数据/索引大小、访问模式、缓存大小和 RAM 大小的组合。不仅仅是您正在查看的数字。
关于MySQL索引长度解释，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29156490/