mysql索引相关

结论：B+tree

链接: 数据结构动画演示

为什么选择这种数据结构？

1. 二叉树: 只是简单的排序（右树大，左树小），而且如果数据按照顺序生成的话，会变成一个单链表
2. 红黑树（平衡二叉树）：因为可以自旋平衡，解决了二叉树的单链表问题，但是由于数据量过大的时候会出现树的深度过大，如果说每一个树节点一次磁盘IO读进内存进行比较会很慢。
3. B-tree（平衡多叉树）：将每个节点变成包含多个索引数据的节点，每次磁盘IO读进内存多个数据，为了减少树的深度，只有增加叉树，这样就变成多叉树了，每个节点既包含了索引还包含其余的数据（注意这个数据可以是数据的地址也可以是真实的数据，这个是跟存储引擎有关，下面会说到），当然不能无脑增加每个节点的索引数量，mysql规定了一个page_size是16k,符合操作系统的处理，这个16k也可以理解为树中的一个节点。
4. B+tree：本质就是B-tree，做了一些优化，将非叶子节点中的数据部分取消了，只留下索引，这样该节点可以放更多的索引，而叶子节点包含所有的索引和数据（这里有个概念叫聚集索引），这也导致前面的索引都是冗余，叶子节点之间还有指针，方便大于小于操作利用索引

myisam和innodb在索引方面的区别？

1. 查看mysql的data目录-》数据库目录-》表文件
   frm结尾的文件是表结构。
2. myisam索引文件（.myi）和数据文件(.myd)是分开2个文件，b+tree最下面的叶子节点中的数据部分是数据的物理地址，也就是数据文件的物理地址，所以需要再去查一次（也叫回表操作），而innodb叶子节点直接就有数据。
3. innodb的文件后缀是(.idb)，维护一个B+tree,必须存在主键（如果没有会找一个唯一列为树的排序列或用rowid自己维护），最好是自增的整形列（相比一些uuid,占用空间小,比较的代价小）。

其余问题

1. hash索引和b+tree索引：hash索引是根据索引列先求hash,然后再去hash表中进行等值比较，直接锁定位置，不利于范围比较，但hash冲突mysql已经做了很好的优化暂不考虑
2. 联合索引：如果单独多个索引，虽然维护多个B+tree但后面的索引列维护的数据部分是主键索引的值，方便数据一致性和减少冗余。使用联合索引其实就是维护一个B+tree，只不过根据最左先排序依次向右进行排序（这也解释了最左原则），当然数据部分是排除索引后的其余列。
3. 一个数据量的计算：一个节点默认是16k,一个bigint主键8B，还有一个指针大小是6B，也就是14B，一个节点可以放16k/14B=1170个，粗略的计算一下，如果树的深度为3，叶子节点中的数据为1k来算，也有16个，1170117016,大约2千万条数据可以容纳。