如果 MySQL 的 InnoDB PRIMARY 列被自动索引，为什么索引长度报告为零？答案

【问题标题】：If MySQL's InnoDB PRIMARY columns are automatically indexed, why is the index length reported as zero?如果 MySQL 的 InnoDB PRIMARY 列被自动索引，为什么索引长度报告为零？
【发布时间】：2014-04-21 18:29:11
【问题描述】：

这是我的 MySQL InnoDB 数据库。注意days 表如何将index length 报告为0。

这是表数据、方案和索引：

如您所见，该表定义了一个PRIMARY 列。这应该被索引，对吧？所以应该有一定的索引长度。

但是，当我实际添加INDEX 列时，例如：

表格突然报告了某个index length，可以在这里看到：

所以我想知道：发生了什么事？索引长度到底是多少？如果它们被索引，为什么它不考虑 PRIMARY 键？

【问题讨论】：

你的主键是一个复合键（多个字段），所以在键中的FIRST字段上报长度，即user。因为days 本质上是捎带，所以它有一个长度为 0 的密钥，因为它已经在用户字段中进行了说明。
@MarcB：你确定这个解释吗？因为这发生在所有未定义 INDEX 并且仅在单个字段上包含 PRIMARY 键的表上。 idPRIMARY、username 的简单表将索引长度报告为 0。

标签： mysql indexing primary-key innodb

【解决方案1】：

InnoDB 根据主键将表行存储在clustered index 中。所以，data_length 显示了主键占用的页面大小。

index_length 显示二级（非主）索引占用的页面大小。

你的评论：

是的，在此表中无需在主键的第一列上创建额外的索引。 MySQL 不会阻止您创建这样一个多余的索引，因为它相信您知道自己在做什么。 :-)

您可以使用pt-duplicate-key-checker 之类的工具来分析您的元数据中是否存在重复索引。在这样一种情况下，我发现由于重复索引而浪费了 400GB 的空间！

【讨论】：

是否意味着将 INDEX 键添加到 USER 列只会产生更多无用数据，因为 USER 已经在 PRIMARY 键中建立索引？