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千万条数据可以容纳。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值