索引的代价

索引的代价

索引系列也写了一些文章了，具体的可以参考

B+树索引（6）之MyISAM索引方案

B+树索引（5）之索引注意事项

B+树索引（4）之索引分类

B+树索引（3）之索引推导优化

B+树索引（2）之索引的推导

B+树索引（1）之为什么需要索引

这些文章就是在分析为什么索引能使查询变快，但加了索引一定好吗？显然并不是，我们需要知道使用索引的代价。

索引的基本结构

在分析索引的代价前我们可以先来回顾下索引的基本结构，索引是一个B+树，由用户记录数据页和目录项数据页构成，如下是一个聚簇索引的基本结构

这颗B+树内部需要维护一些排序

• 用户记录数据页（叶子节点）：用户记录与用户记录之间采用主键值进行排序由小到大，并且采用记录头属性next_record形成单向链表。

• 数据页与数据页之间：同样采用主键值排序，采用File Header的上一页下一页属性形成双向链表。

• 目录项记录数据页（非叶子节点）：非叶子节点的记录项同样采用主键值排序，和叶子节点不同的是该页记录只有主键值和页号，而叶子节点记录有完整用户记录。

索引的代价

回顾完索引的基本结构后，我们就可以来讨论索引所需要的代价！

空间上的代价

从上面B+树结构我们知道，每创建一个索引就需要创建一颗B+树，每一个B+树都是由数据页构成，一个数据页默认大小是16K，一颗很大的B+树显然需要很多数据页构成，所以需要占用很大一片空间存放。

时间上的代价

因为索引的B+树内部需要始终需要维护固定列值排序，所以对表数据的增、删、改，都需要去修改B+树索引结构，其后果可能就是造成记录移位、页面分裂、页面回收等，如果一个表有太多的索引那么在维护B+树索引结构排序上面所花的时间将是巨大，换句话说就是索引越多维护成本越大。

总结

一谈到Mysql表的性能优化，谈及最多的就是加索引，但索引虽好但不能随意创建，创建一个索引会带来时间上和空间上的性能消耗，所以我们在创建索引时需要尽量将索引发挥出最大的性能！