问InnoDB B+树索引-重复值

EN

从某种意义上说，InnoDB BTree没有复制项。这是因为PRIMARY KEY的列被附加到为辅助键指定的列中。这就形成了一个完整有序的列表。

当您通过辅助键(或键的初始部分)进行查找时，查询将向下钻取BTree以查找索引中与您给定的内容相匹配的第一行，然后向前扫描以获得任何其他行。要获得其余的列，需要使用PRIMARY KEY列进行第二次BTree查找。

优化器很少使用具有“低基数”的索引。例如，不应将“是/否”或“真/假”或“男/女”列编入索引。优化器会发现更快的是简单地扫描表，而不是在索引和(通过PK列)主BTree之间来回跳。

何时使用该指数的截止点在20%左右，这取决于月亮的相位。

坏指数

对于B+树来说，您提议的情况是不好的。基数为10表示only 10 of the 1 million values are unique。实际上，它不仅对B+树不利，在一般情况下它也是一个糟糕的索引。根据这个索引，您将平均留下一个大约的子集。100,000个值，您必须查看这些值，或者使用另一个值来进一步筛选。

B+树性质

关于结果树的结构，这里有一些需要记住的事情：

1. 节点不能包含任意的大量数据。

• 如果叶节点已满，则插入可能需要拆分。
• 有时，叶子节点的分裂需要下一个更高的节点的分裂。
• 在最坏的情况下，拆分可能一直级联到根节点。

https://www.percona.com/files/presentations/percona-live/london-2011/PLUK2011-b-

1. 叶子是以双链接列表的形式链接的。

• 叶节点作为双链接列表链接在一起。
• …
• 整个树可以被扫描而不访问更高的节点。

https://www.percona.com/files/presentations/percona-live/london-2011/PLUK2011-b-

期望值

如果您用键插入了很多数据，这些键或多或少都属于相同的等价类，那么我希望有一棵树，它不会有多大帮助。这10个键可能只存在于根节点中，而树中更深的所有数据都将被取消排序(因为没有什么可排序的了)。

由于leafs是双链接列表，所以基本上只剩下我在开头所写的内容:您必须遍历大量的值。关于给定的索引，这必须是预期的，而且B+树在这种情况下可能会做得很好(只需要查看所有数据，列表就可以了)。

实际上，这是一个更深层次的抽象:叶是双链接的，但是每个叶中有多个值(数据或PK链接)。尽管如此，这些也在一个列表中，所以如果你只是遍历所有的东西，它就不会有多大的区别。

检查InnoDB空间

请注意，您也可以调查MySQL到底在构建什么。有检查生成的索引数据结构的工具，例如，请参阅

• https://blog.jcole.us/2013/01/10/btree-index-structures-in-innodb/
• ruby

InnoDB将表存储在名为内部主索引的B+树索引中。索引的键是您的主键字段。

如果定义辅助索引，则会有附加的B+树索引(在.ibd或ibdata1中)，其中键是辅助索引字段，值是主键。

B+树本身不要求密钥是唯一的。主索引和所有唯一索引的唯一性在服务器级别强制执行。

下面是一些关于InnoDB如何组织索引并使用它们访问数据的幻灯片。http://www.slideshare.net/akuzminsky/efficient-indexes-in-mysql#downloads-panel