设计类招聘网站,库尔勒市建设路街道办网站,微信营销方案,上海网站制作 公司mysql#xff0c;对it打工人#xff0c;这个几乎是必备的技能之一。mysql可以解决我们平时工作中的大量的、有关增删查改的问题。所以想深入了解mysql#xff0c;我觉得关键在于他的增删查改背后的算法#xff0c;开搞。面对增删查改等问题#xff0c;直接通过场景来看吧场…mysql对it打工人这个几乎是必备的技能之一。mysql可以解决我们平时工作中的大量的、有关增删查改的问题。所以想深入了解mysql我觉得关键在于他的增删查改背后的算法开搞。面对增删查改等问题直接通过场景来看吧场景1有很多个数据如上图右边的两个链表顺序查找会会遍历每一个元素会很慢尤其是数据量很大的时候遍历整个表都会会一次都会消耗大量的时间而右边是一个二叉树很明显可以看到二叉树找到我们要的元素最多只需要比对3次。常见的各种树的算法复杂度操作二叉查找树平衡二叉树红黑树查找O(n)O(logn)Olog(n)插入O(n)O(logn)Olog(n)删除O(n)O(logn)Olog(n)结论链表不得行哦~直接上二叉树吧于是乎制作成二叉树如下图右边的树。左边的链表89号元素需要遍历查找而89的元素在在二叉树中一次比对后就完成了定位。所以单一个二叉树就大大的优化了效率。mysql有使用二叉树吗没有为什么呢想想一下这个一个场景有一堆连续的数组放到二叉树里边那么他的二叉树结构就是一个链表的样子说明了说在个别场景中二叉树相对链表并没有优势可言。ps安利一个网站https://www.cs.usfca.edu/~gal...结论就是二叉树也不见得很好个别场景下它就是个链表红黑树(二叉平衡树)于是乎来到了红黑树如下图。性质1每个节点要么是黑色要么是红色。性质2根节点是黑色。性质3每个叶子节点(NIL)是黑色。性质4每个红色结点的两个子结点一定都是黑色。性质5任意一结点到每个叶子结点的路径都包含数量相同的黑结点。红黑树的应用比较广泛主要是用它来存储有序的数据它的时间复杂度是O(lgn)效率非常之高。TODO补充红黑树的伪算法这样看起来红黑树效率会高一些但是为什么mysql用的不是红黑树呢因为实际场景的时候数据量会很大比如几百万的时候树的层级可能达到20层其实这个速度是很快了但是依然不够高。在数据量大的时候查找速度慢它很难避免。到这里可以得出数据查询的效率跟数据层级是有关系的所以这里是不是可以思考一下我们就让这个红黑树高度可控控制在一个指定的深度比如就三层就会快很多这样子做得话我们只能在一个节点上挂载更多的节点而不是只是两个。实际上这就是b树看上去b树效果已经很好了mysql有用到吗 NO实际上mysql用的是b树b树和b树在底层存储数据的区别叶子节点有一个指针指向左右这样可以按照顺序地在叶子节点上遍历数据。在mysql中b树的特点mysql的b树的第一层节点的大小是16kb。可以通过sql语句查询到show global status liek innodb_page_size。其实第一层大索引大致可以存放(86)的数量是1170个的样子第二层的节点也是1170个样样子。第三场就单纯存放索引大概存放16个。所以mysqlb树的索引大概可以存放的数据量在2000万个左右。其实实际情况中根节点的数据是常驻内存的并不是每次查询都会重新载入一遍到内存。所以千万级别的表查找依然很快。实际上b树的层级是可以大于3层的需要的话可以设置。单实际上到这一步的时候早就应该分库分表的。也就是为什么mysql不建议存储数据量大于2000万行左右数据的一个原因。MyISAM和innodb的区别tipsmyisam引擎mysql数据文件夹里边的文件简介frm存放的是表结构MYD是存放的数据MYI存放的树索引。那么myisam的数据内容就是当查找col1(假如col1是索引)等于30是就是去myi的的文件里边找按照左边的这个树形结构定位到数据地址拉出里边的索引位置。通过索引记录的位置迅速定位到数据表的行的地址。这就是MYIsam但实际中我们用的更多是innodb的引擎为什么要用innodb呢innodb的文件结构。innodb在mysql数据库文件夹下的数据文件格式是frm代表表结构文件, idb存放的既包含数据又包含索引。这几个名称猴嘴的mysql文件相信做过数据迁移的童鞋都不会觉得陌生甚至看到他会有一丝丝气愤当初就是这些让自己经常加班所以可以看出innodb叶子节点上存放的不是索引而直接是数据。Innodb的数据是直接挂在索引下的那么这些差异导致不同引擎的数据库都有哪些差异呢好几种索引介绍聚集索引(聚蔟索引)innodb叶子节点包含了完整数据的索引。非聚集索引(离散索引)myslam 叶子节点上没有存放完整的数据。为什么innodb表建议必须建主键并且推荐使用整形的自增主键呢uuid不合适开篇死。因为uuid不是递增的因为innodb的数据必须有一个b树的索引结构来组织他的数据。mysql如果不建立主键他就会进入这张表的第一列判断如果这列数据每一个数据都是唯一的那么就用这一列当做索引。如果遍历完了每一列都没有唯一的列那么mysql就会悄悄地为你建立一列隐藏列。这样一下走下来就花费了太多运算了所以推荐用户自建自增索引。为什么建议自增整形呢(雪花算法也是自增的。)因为查找的时候需要经常比对大小每一层会逐个比对大小用asii码去比对。而整形在这一块比对的时候会快一些所以要求整形。为甚自增呢为了快。比如遇到范围查询的时候定位到了一个元素是不是就很快能判断上下位置的元素。建立索引的时候可以选择btree还有hash。hash是什么样的呢hash定位速度很快哦。超级快首先算hash值然后根据hash存放在某个位置这个数据里边存放了值和节点的地址。当有多个的时候就在这个后边直接添加。当数据量不大的时候hash的效率非常高。但实际上工作用绝大多数的时候都用的是b而不是hash(99.99%都不是)。为什么呢hash冲突只是一个最主要的是不支持范围查询。当有返回查询的时候就只能遍历查询。所以范围查询hash挂掉了那么b树就能hold住吗b树的叶子节点有一个双向指针来保持数据的连贯性。此外b数据帮我们维护了一个从做到右的一种递增结构。所以范围查询只要定位到了上限或者下限直接顺藤摸瓜很快就能完成定位。这也是为什么b树叶子节点要维护一个双向指针的原因。即使你没有按照顺序存放数据b树也会帮你整理好顺序。比如7,8,6,也会将6放到78前。所以如果不是递增调整顺序会消耗计算尤其是在节点分裂的时候要影响整个树的结构的时候结构变化就会占用很多资源。但是如果顺序存放反正结构性调整的概率是比较低的相当于也是加快了存储的顺序。这也是添加了索引为什么会让存储变慢的底层原因。常见的联合索引的底层存储结构长什么样子的从上图可以看一下二级索引的特点二级索引紧贴在一级索引后边question为什么二级索引长成这样实际使用时运作机制是什么样的。其实索引是一种排好序的数据结构想要理解多级索引的特点其实理解好mysql处理索引时是如何为多级索引排序的就好了。其实查找时方法就是逐个比对。如果第一层就已经可以比对处顺序了那么这些数据就直接就按这个顺序来排就行。如果第一个索引大小相同那就根据第二个来排序如果第二个相同就看第三个。如果第三个也相同就看主键如果没有主键那就看隐藏主键(所以建立自增索引很重要)。
