MySQL 索引的大小是表大小的 12 倍，原因有哪些？

Question

因此，我们有一个表，该表有两个索引，一个索引在主键上，另一个索引在表的另一列上。索引大小目前是表本身的 12 倍。发生这种情况的原因有哪些？我们之前优化过该表，这很有帮助，但它又增长了。

谢谢！

Answer 1

这种大小在索引中并不罕见，尤其是对于大型文本字段。虽然这可能表明索引策略不佳，但文本的索引显然比数字更复杂，尤其是在启用不锚定在文本字段开头的子字符串搜索时。

虽然大型索引本质上看起来很慢，但由于其高度结构化的特性，它可以（或应该）相当快速地导航，因此比对数据本身进行详尽搜索更快地产生指向正确数据的指针。

假设索引仍能容纳在磁盘上，索引的真正考验是令人满意的搜索、更新和添加时间，尤其是在数据量增加的情况下。如果这些方面仍然足够，那么大型索引是可以容忍的。

Answer 2

可能对指数规模产生负面影响的因素

• 数据分布（即数据是均匀的还是有偏差的）
• 数据插入/删除/更新的顺序（即如果它不是随机的）
• 对于 varchar，varchar 的大小和字符集
• 对于 innodb，为主键使用不必要的大数据类型将影响每个索引的贡献，因为它隐式地是它的一部分

正如您提到的，重写索引（即优化表）可以/将再次平衡索引结构。