MySQL索引长度解释

看看下面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\u rows

是表中的行数。这个数字对于MyISAM来说是精确的，但对于InnoDB来说只是近似值

data\u length

是表中数据部分的字节数。对于InnoDB，这包括

主键

index_length

是索引的字节数（不是行数）（不包括InnoDB的主键）

如果有大量索引，则索引长度可以大于数据长度。这是一个提示，您可能有太多的索引，但这并不一定是“坏的”

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

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

当事物变得更大时，就会发生退化。但这并不是那么简单

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

示例2：有些查询需要扫描整个表或整个索引。这会破坏缓存，性能也会急剧下降

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

---

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

索引基于数据，而不是表行。“在性能开始快速下降之前，索引的长度是否有限制？”——是的。一旦它不能完全进入记忆。