InnoDB -> Int vs VarChar 的键数答案

【问题标题】：InnoDB -> Number of keys for Int vs VarCharInnoDB -> Int vs VarChar 的键数
【发布时间】：2017-02-02 01:30:11
【问题描述】：

我正在阅读各种论坛和堆积如山的问题，但找不到我的答案。

我正在尝试找出将存储在 16KB InnoDb 数据库页面中的密钥数量。

正如您在this forum 中看到的，他们提到了如何在单个页面中计算 MyISAM 的密钥数量。我想对 InnoDb 做同样的事情。我不明白这些计算是如何进行的。

我正在比较一个 4KB 的 int 和一个 VARCHAR (200)。如果我能得到这个计算，那就太好了。

【问题讨论】：

标签： mysql indexing innodb

【解决方案1】：

索引结构为 BTree。
InnoDB BTree 最初仅填充 15/16 满。
经过大量流失后，BTree 平均为 69%。
索引条目中的每个“行”都会产生大量开销。
PRIMARY KEY（在 InnoDB 中）与数据“聚集”在一起。所以只有非叶子节点会占用额外的块。
二级索引包含PRIMARY KEY的所有列；这就是他们“指向”记录的方式。
基于以上两项，在BTree中只包含INT作为索引是没有意义的。

我使用简单的经验法则：每个 BTree 100 个“行”。
推论：一百万行的 BTree 大约有 3 层深；十亿行的表大约有 5 层深。

让我们来看看这个：

CREATE TABLE x (
    id INT ...,
    num INT ...,
    str VARCHAR(200) CHARACTER SET utf8,
    PRIMARY KEY (id),
    INDEX i_num (num),
    INDEX i_str (str)
) ENGINE=InnoDB;

对于i_num，请注意有两个INTs。每个块您可能会获得 300-400 个“行”。 1000 万行需要 3 个级别。

对于i_str，我们假设平均有 100 个韩语字符，即文本的 300 个字节。每个块您可能会得到 25-35 个“行”。 10M 行需要 5 个级别。

ALTER 和 OPTIMIZE 可能也可能不对索引进行碎片整理。

information_schema 表提供了一些关于每个 BTree 及其级别的详细信息。 Percona 和 MySQL 有不同的表。

底线：计算太模糊而无法准确。我希望我的挥手能给你一些更好的处理。

【讨论】：