台州市临海建设局网站,虚拟空间网站回收池有什么作用,wordpress用户验证失败,企业建网站选中企动力Mysql客户端包括JDBC、 Navicat、sqlyog#xff0c;只是为了和mysql server建立连接#xff0c;向mysql server提交sql语句。mysql server组件第一部分叫连接器主要承担的功能叫管理连接和验证权限#xff0c;每次在进行数据库访问的时候#xff0c;必然要输入用户名和密码…Mysql客户端包括JDBC、 Navicat、sqlyog只是为了和mysql server建立连接向mysql server提交sql语句。mysql server组件第一部分叫连接器主要承担的功能叫管理连接和验证权限每次在进行数据库访问的时候必然要输入用户名和密码进行权限的验证之类的。查看当前数据库正在建立的连接有几个:第二个部分叫分析器sql语句就是一堆的字符串server拿到这一系列字符串之后需要对当前字符串进行解析操作最终一个sql语句无论多简单都会转换成一个树形结构AST 抽象语法树这里面会做2个基本操作一个是词法分析一个是语法分析最终会转换成一个抽象语法树sql语句在正常执行的时候都是按照这样一个树形结构来执行的。一般情况下sql语句在进行语法分析的时候根据输入自动生成语法树并可视化显示出来。开源的语法分析器常用的2个组件是Antlr、Apache Calcite如果公司自研sql中间件可能会涉及到sql语句解析工作可以基于这2个组件来实现。将这个sql语句转换成这样的树形结构绿色的代表关键字token按照这样的树形结构来进行具体server的解析工作。第三部分叫优化器对于这样的sql语句先读取t1表还是先读取t2表这是优化器来选择的主要依据于2个标准第一个标准叫RBO第二个标准叫CBORBO基于规则的优化CBO是基于成本的优化现在主流的数据库CBO用的是比较多的RBO用的比较少。第四个组件-执行器执行sql执行器是需要和存储引擎进行交互的需要从存储引擎里面把数据查询出来并且返回给客户端怎么理解存储引擎mysql的数据文件存在磁盘不同的存储引擎在磁盘上的存储形式是不一样的不同的数据文件在磁盘是不同组织形式统一的概述叫存储引擎。Innodb存储引擎文件中有2个同名的文件frm(表结构相关的元数据信息)和ibd(数据文件和对应的索引文件)。**MyISAM存储引擎文件中有3个同名的文件frm(表结构相关的元数据信息)和MYD数据和MYI索引数据文件和索引文件是分开的。还包含一个查询缓存组件8.0以上取消了因为数据命中率非常低需要经常的更新里面的数据。为什么要使用B树这样的数据结构自己设计的话怎么设计索引的意义是加快数据访问提高查询效率数据存储在磁盘从磁盘中读取效率很低特别是在读取大量数据的时候瓶颈是卡在硬件层面。将电脑机械硬盘换成SSD固态硬盘速度快在软件设计的时候可以对io操作进行相关的优化优化的时候可以考虑2个纬度1、尽可能读取少量的数据减少io量2、减少io次数数据是存储在磁盘的从磁盘读取数据的时候需要涉及到磁体的移动或者说寻址的时间这都是太浪费时间的所以能一次性读取就不读取2次。索引到底要存储什么样的数据索引的数据格式是什么一个非常大的文件里面存储一行一行的数据如何去定位我想要的数据在哪个位置并且如何把对应数据位置的数据读取出来应该选择什么样的数据格式来存储数据在创建索引的时候一定有个key值每次根据key找到了整行的value值k是字段信息v是文件名称以及偏移量可以把当前数据读取出来以及读取的数据长度这样的结构会有一个非常大的问题当数据文件变的越来越大的时候当前存储索引的文件有可能会变得非常大数据文件和索引文件的可能会变得非常大有必要在索引文件的前面再给它建一个索引不断的在前面加索引这很明显是不合适的。OLAP联机分析处理主要对历史数据进行分析产生决策不要求短时间内返回结果比如数据仓库HIVE在HIVE中索引确实是这样的方式存在的但不要求短时间内返回结果OLTP联机事务处理支撑业务系统的需要在短时间内返回对应的数据结果比如数据库mysql必须在秒级别和毫秒级别返回数据。存储k-v格式的数据需要使用什么样的数据结构?哈希表、二叉树、红黑树、B树、B树这些数据结构都是存储k-v格式的数据。把磁盘所有的数据文件全部一口气读取到内存把所有的索引文件都放入内存这是不太可能的所以需要分块读取分而治之很多大数据设计都用了这个理念。哈希表存在什么样的问题使用哈希表的意义是为了让数据尽可能的散列因此在使用哈希表的时候要选择合适的哈希算法避免hash碰撞 和哈希冲突。如图所示数据不是散列均匀的数据都集中在1和3号位置哈希表存储的数据是无序的当需要进行范围查询的时候只能进行挨个遍历对比效率极低哈希表在读取数据的时候不能一块一块去读。虽然索引没有hash表的数据结构但是mysql里面有hash索引mysql中的memory存储引擎支持哈希索引innodb存储引擎支持自适应hash。二叉树BSTbinary search tree 二叉搜索树AVL平衡二叉查找树红黑树这四个的共同点是最多只能有2个分支BST、AVL、红黑树这3个是有序的左子树必须小于根节点右子树必须大于根节点AVL和红黑树都是平衡的。三层的树结构存满之后最多可以装多少条数据2的3次方-17条如果想存储更多的数据只能将树的高度提高变成四层或五层或更多层层数变多会有什么影响吗io次数会变多磁盘预读内存跟磁盘进行数据交互的时候有一个最基本的逻辑单位称之为页或datapage页的大小是跟操作系统相关的一般是4kb或8kb在进行数据读取的时候一般操作的是页的整数倍。当这里有一个页的概念了内存和磁盘交互的时候是有页了和刚才说的分而治之关联起来这里就是天然的分好的块了。页如果存不满可以放其他东西吗8bit(位) 1Byte (字节)1024Byte(字节)1KB占不满还是占4KB的空间。每一个节点如果只能存储一个数据值的话如果想让它存储更多数据的话要加层每一层或每一个节点里面读取的时候都是一页一页的层数加多了会导致io量变多。既要尽可能多的存储数据还要减少io的次数减少树的高度如果不能变高那这个树可以变形吗如果一个节点放多个值呢原来是二叉树让当前这个结构变形为多叉树当变成多叉树之后就意味着孩子节点变多了树变矮了有序 且平衡就变成了一个B树了。需要把这个B树模型做一个过渡用来存数据库表和行数据这个值变成几种类型的数据首先第一个存放数据的时候key值是要有的根据key值检索到对应的数据。每个方块就代表读取的n个页的信息每次在进行数据交互的时候读取页的整数倍每个方块表示读页的整数倍 默认假设16kb每个磁盘快包含三种类型的数据16、32表示具体的key值data表示实际的行数据p1表示实际的指针。3层的树如果要读取28这条数据的话先读取磁盘块1把28和36、34对比正好在中间沿着p2指针把磁盘块3读取过来把磁盘块3读取过来之后再把28和25、31对比正好在中间把磁盘块8读取出来一共读取了3个磁盘块。在innodb存储引擎里面有一个变量默认读取16kb的数据每个磁盘块占16k一共读了48kb的数据如果这个B树只有3层存满了之后可以存多少条数据假设一个data占1kb磁盘块1最多能有几个子节点最多15个data16个范围最多有16个子节点每层16三层16 x *16 x *16 4096条记录为什么三层的B树只能存4000条数据谁占用了大量的存储空间是data能不能把data去掉所以在B树的基础之上有了B树B树数据没有重复的B树叶子节点包含了全量的数据非叶子节点包含了部分数据即有一定数据冗余。所有的data都放到叶子节点里面去了非叶子节点不存储实际的数据只有在叶子节点才会存储实际的数据这样的一个3层B Tree如果存满的话可以支持多少数据量的存储一个磁盘块16kb读一次3层3个磁盘块比如读取磁盘块1-磁盘块3-磁盘块7依然读取了48kb的数据假设磁盘块1中的p128占了10个字节16*1024/10大约1600个子节点第二层一个磁盘块也是1600个节点第三层只能存16条存满的话1600 x 1600 x 1640960000千万级别。Btree的索引一般是3层一般情况下3-4层的Btree足以支撑千万级别的数据量存储刚刚计算公式谁占了绝大部分空间指针的大小是不变的索引列的值是有可能会变化的索引影响最大的是key这个值所以要保证key尽可能小的占用存储空间。在创建索引的时候用int类型好还是varchar类型好int占4个字节但是varchar占用的字节是自己指定的比如varchar(3)即谁占用的空间小就用哪个列作为索引。mysql表创建的时候主键要不要自增在满足业务系统支撑的情况下尽可能的自增这里面会涉及到索引的维护。假设磁盘块5最多只能放4条记录当存满了之后要插入一条14的记录底层的叶子节点是有顺序的所以要把磁盘块5拆分成2个磁盘块11、12和13、15分开之后上层磁盘块2也需要增加一个指针如果磁盘块2也满了也要分裂成两个....所以在进行数据插入的时候有可能会影响到上层的新增就会很麻烦。而递增后到效果是在后面追加就行了对上层没有影响所以在满足业务系统的情况下尽可能的自增而分布式环境下可以通过雪花算法自增。
