查看以下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
答案 0 :(得分：3)
table_rows是表格中行的数量。这个数字对于MyISAM来说是准确的，但只是InnoDB的近似值。 data_length是表格数据部分中 bytes 的数量。对于InnoDB，这包括PRIMARY KEY。 index_length是索引的 bytes （不是行）的数量（如果是InnoDB，则不包括PK）。
如果您有大量索引，index_length可能大于data_length。这是一个线索，你可能有太多的索引，但这不一定是＆＃34;坏＆＃34;。
每个索引都存储为独立的BTree。当你添加另一个索引时，你得到另一个BTree;这 not 会影响现有索引的性能。
你的桌子有几百万行;这意味着每个BTree的深度大约为4级。如果该表增长到十亿行，其BTree将增长到大约5个级别。这是次要的。
当事情变大时，可能会发生降级。但事情并非那么简单。
示例1：您的数据具有日期时间索引或auto_increment PRIMARY KEY，并且您始终只查看＆＃34;最近的＆＃34;行。在这种情况下，可能是＆＃34;工作集＆＃34;足够小，可以放入RAM。您不会注意到任何性能下降的数据和数据。指数增长。
示例2：某些查询需要扫描整个表或整个索引。这会破坏缓存，性能也会下滑。
示例3：UUID的索引。这是非常随机索引。 ＆＃39; next＆＃39;您插入或选择的UUID与您最近触及的其他人没有任何关系。因此，一旦数据/索引对于RAM太大，您可能需要访问磁盘。在这里，表现逐渐恶化。
我的观点是性能下降是数据/索引大小，访问模式，缓存大小和RAM大小的组合。不只是你正在看的数字。