建设银行网站个人银行上不去,企业wordpress主题免费下载,wordpress参数手册,标准企业网站开发合同文章目录 建立测试表插入多条记录查看插入结果中断一下---为何IO交互要是 Page重谈page理解单个page理解多个page 页目录单页情况多页情况复盘一下InnoDB 在建立索引结构来管理数据的时候#xff0c;其他数据结构为何不行#xff1f;B vs B聚簇索引 VS 非聚簇索引 建立测试表… 文章目录 建立测试表插入多条记录查看插入结果中断一下---为何IO交互要是 Page重谈page理解单个page理解多个page 页目录单页情况多页情况复盘一下InnoDB 在建立索引结构来管理数据的时候其他数据结构为何不行B vs B聚簇索引 VS 非聚簇索引 建立测试表 插入多条记录 查看插入结果 发现竟然默认是有序的 我们向一个具有主键的表中乱序插入数据发现数据会自动排序。 谁做的mysql 为什么这么做问题1
中断一下—为何IO交互要是 Page
为何MySQL和磁盘进行IO交互的时候要采用Page的方案进行交互呢?用多少加载多少不香吗?
如上面的5条记录如果MySQL要查找id2的记录第一次加载id1第二次加载id2一次一条记录那么就需要2次IO。如果要找id5那么就需要5次IO。
但如果这5条(或者更多)都被保存在一个Page中(16KB能保存很多记录),那么第一次IO查找id2的时候整个Page会被加载到MySQL的Buffer Pool中这里完成了一次IO。但是往后如果在查找id1,3,4,5等完全不需要进行IO了而是直接在内存中进行了。所以就在单Page里面大大减少了IO的次数。
你怎么保证用户一定下次找的数据就在这个Page里面我们不能严格保证但是有很大概率因为有局部性原理。往往IO效率低下的最主要矛盾不是IO单次数据量的大小而是IO的次数。
重谈page
理解单个page
如何理解mysql中page的概念 mysql内部一定需要并且会存在大量的page也就决定了mysql必须要将对个同时存在的page管理起来
这是就用到了之前学的六字真言要管理所有mysql的page需要先描述再组织
所以不要简单的认为page是一个内存块page内部也必须写入对应的管理信息 不同的 Page 在 MySQL 中都是 16KB 使用 prev 和 next 构成双向链表。
将所有的page用“链表”的形式管理起来--在buffer pool内部。
因为有主键的问题 MySQL 会默认按照主键给我们的数据进行排序从上面的Page内数据记录可以看出数据是有序且彼此关联的。
为什么数据库在插入数据时要对其进行排序呢我们按正常顺序插入数据不是也挺好的吗
插入数据时排序的目的就是优化查询的效率。
页内部存放数据的模块实质上也是一个链表的结构链表的特点也就是增删快查询修改慢所以优化查询的效率是必须的。
正式因为有序在查找的时候从头到后都是有效查找没有任何一个查找是浪费的而且如果运气好是可以提前结束查找过程的。理解多个page
通过上面的分析我们知道上面页模式中只有一个功能就是在查询某条数据的时候直接将一整页的数据加载到内存中以减少硬盘IO次数从而提高性能。但是我们也可以看到现在的页模式内部实际上是采用了链表的结构前一条数据指向后一条数据本质上还是通过数据的逐条比较来取出特定的数据。如果有1千万条数据一定需要多个Page来保存1千万条数据多个Page彼此使用双链表链接起来而且每个Page内部的数据也是基于链表的。那么查找特定一条记录也一定是线性查找。这效率也太低了。 页目录
我们在看《谭浩强C程序设计》这本书的时候如果我们要看指针章节找到该章节有两种做法
从头逐页的向后翻直到找到目标内容通过书提供的目录发现指针章节在234页(假设)那么我们便直接翻到234页。同时查找目录的方案可以顺序找不过因为目录肯定少所以可以快速提高定位本质上书中的目录是多花了纸张的但是却提高了效率所以目录是一种“空间换时间的做法”
单页情况
针对上面的单页Page我们能否也引入目录呢当然可以 那么当前在一个Page内部我们引入了目录。比如我们要查找id4记录之前必须线性遍历4次才能拿到结果。现在直接通过目录2[3]直接进行定位新的起始位置提高了效率。 现在我们可以再次正式回答上面的问题了所以为何通过键值 MySQL 会自动排序 问题1答案可以很方便的引入目录
多页情况
MySQL 中每一页的大小只有 16KB 单个Page大小固定所以随着数据量不断增大 16KB 不可能存下所有的数据那么必定会有多个页来存储数据。 在单表数据不断被插入的情况下 MySQL 会在容量不足的时候自动开辟新的Page来保存新的数据然后通过指针的方式将所有的Page组织起来。
需要注意上面的图是理想结构大家也知道目前要保证整体有序那么新插入的数据不一定会在新Page上面这里仅仅做演示。
这样我们就可以通过多个Page遍历Page内部通过目录来快速定位数据。可是貌似这样也有效率问题在Page之间也是需要 MySQL 遍历的遍历意味着依旧需要进行大量的IO将下一个Page加载到内存进行线性检测。这样就显得我们之前的Page内部的目录有点杯水车薪了。
那么如何解决呢解决方案其实就是我们之前的思路给Page也带上目录。
使用一个目录项来指向某一页而这个目录项存放的就是将要指向的页中存放的最小数据的键值。和页内目录不同的地方在于这种目录管理的级别是页而页内目录管理的级别是行。其中每个目录项的构成是键值指针。图中没有画全。 存在一个目录页来管理页目录目录页中的数据存放的就是指向的那一页中最小的数据。有数据就可通过比较找到该访问那个Page进而通过指针找到下一个Page。
其实目录页的本质也是页普通页中存的数据是用户数据而目录页中存的数据是普通页的地址。
可是我们每次检索数据的时候该从哪里开始呢虽然顶层的目录页少了但是还要遍历啊 不用担心可以在加目录页 这货就是传说中的B树啊? 没错至此我们已经给我们的表user构建完了主键索引。
随便找一个id我们发现现在查找的Page数一定减少了也就意味着IO次数减少了那么效率也就提高了。
复盘一下
Page分为目录页和数据页。目录页只放各个下级Page的最小键值。查找的时候自定向下找只需要加载部分目录页到内存即可完成算法的整个查找过程大大减少了IO次数
InnoDB 在建立索引结构来管理数据的时候其他数据结构为何不行
链表线性遍历二叉搜索树退化问题可能退化成为线性结构AVL红黑树虽然是平衡或者近似平衡但是毕竟是二叉结构相比较多阶B意味着树整体过高大家都是自顶向下找层高越低意味着系统与硬盘更少的IOPage交互。虽然你很秀但是有更秀的。Hash官方的索引实现方式中MySQL 是支持HASH的不过 InnoDB 和 MyISAM并不支持.Hash跟进其算法特征决定了虽然有时候也很快(O(1))不过在面对范围查找就明显不行另外还有其他差别有兴趣可以查一下。 B树最值得比较的是 InnoDB 为何不用B树作为底层索引
B vs B
B树 B树 目前这两棵树对我们最有意义的区别是
B树节点既有数据又有Page指针而B只有叶子节点有数据其他目录页只有键值和Page指针B叶子节点全部相连而B没有
B树特点
1.叶子节点保存有效数据路上节点没有非叶子节点不保存数据只保存目录项2.叶子节点全部用链表级联起来非叶子节点不存数据可以存储更多的目录项目录页可以管理更多的叶子page。3.B树是矮胖型的
B树是矮胖型的优点 途径的路上节点减少-找到目标数据只需要更少的pageIO次数少IO层面提高了效率-每一个节点都有目录项可以提高搜索效率(整体搜索效率也随之提高了)
所以为何选择B树
节点不存储data这样一个节点就可以存储更多的key。可以使得树更矮所以IO操作次数更少。叶子节点相连更便于进行范围查找
一般我们建表插入数据的时候就是在该结构下进行CURD我的表没有主键怎么帮呢也是这样吗对的
B树结构被构建在mysql的缓冲区中。
聚簇索引 VS 非聚簇索引
MyISAM 存储引擎-主键索引
MyISAM 引擎同样使用B树作为索引结果叶节点的data域存放的是数据记录的地址。下图为 MyISAM 表的主索引Col1 为主键。 其中 MyISAM 最大的特点是将索引Page和数据Page分离也就是叶子节点没有数据只有对应数据的地址。相较于 InnoDB 索引 InnoDB 是将索引和数据放在一起的。 其中 MyISAM 这种用户数据与索引数据分离的索引方案叫做非聚簇索引
其中 InnoDB 这种用户数据与索引数据在一起索引方案叫做聚簇索引
当然 MySQL 除了默认会建立主键索引外我们用户也有可能建立按照其他列信息建立的索引一般这种索引可以叫做辅助普通索引。
对于 MyISAM ,建立辅助普通索引和主键索引没有差别无非就是主键不能重复而非主键可重复。
下图就是基于 MyISAM 的 Col2 建立的索引和主键索引没有差别 同样 InnoDB 除了主键索引用户也会建立辅助普通索引我们以上表中的 Col3 建立对应的辅助索引如下图
可以看到InnoDB 的非主键索引中叶子节点并没有数据而只有对应记录的key值。
所以通过辅助普通索引找到目标记录需要两遍索引 首先检索辅助索引获得主键然后用主键到主索引中检索获得记录。这种过程就叫做回表查询
为何 InnoDB 针对这种辅助普通索引的场景不给叶子节点也附上数据呢 原因就是太浪费空间了。
