update的执行 从客户端 => ··· => 执行引擎
是一样的流程,都要先查到这条数据,然后再去更新。要想理解 UPDATE
流程我们先来看看,Innodb的架构模型。
这里有个关键点,当我们去查询数据时候会先 拿着我们当前查询的 page
去 buffer pool
中查询 当前page
是否在缓冲池
中。如果在,则直接获取。
而如果是update操作
时,则会直接修改 Buffer
中的值。这个时候,buffer
pool
中的数据就和我们磁盘中实际存储的数据不一致
了,称为脏页
。每隔一段时间,Innodb存储引擎就会把脏页数据
刷入磁盘。一般来说当更新一条数据,我们需要将数据给读取到buffer
中修改,然后写回磁盘,完成一次 落盘IO
操作。
为了提高update
的操作性能,Mysql在内存中做了优化,可以看到,在架构图的缓冲池
中有一块区域叫做:change buffer
。顾名思义,给change后的数据,做buffer的
,当更新一个没有 unique index
的数据时,直接将修改的数据放到
change buffer
,然后通过 merge
操作完成更新,从而减少了那一次 落盘的IO
操作。
没有唯一索引的数据更新时
,为什么必须要没有唯一索引的数据更新时
才能直接放入change
buffer
呢?如果是有唯一约束的字段
,我们在更新数据后,可能更新的数据和已经存在的数据有重复,所以只能从磁盘中把所有数据读出来比对
才能确定唯一性。
这样就可以在,当数据库崩溃的后,直接从 redo log
中恢复数据,保证数据的正确性
redo log 默认存储在两个文件中 ib_logfile0
ib_logfile1
,这两个文件都是固定大小的
。为什么需要固定大小?
这是因为redo log
的 顺序读取
的特性造成的,必须是连续的存储空间
一般我们的数据都是分散在磁盘上的:
机械硬盘的读写顺序是:
其实不管机械还是固态,我们去存储时,都是通过文件系统
与磁盘打交道的,而他们打交道的方式就有两个。随机读写
和顺序读写
块
(默认 1block=8扇区=4K)
一串连续的块
中,这样读取速度就大大提升了
在这里,redo log具体的执行策略有三种:
Log Buffer
,只需要每秒写redo log 磁盘数据一次,性能高,但会造成数据 1s 内的一致性问题。适用于强实时性
,弱一致性
,比如评论区评论
Log Buffer
,同时写入磁盘,性能最差,一致性最高。 适用于弱实时性
,强一致性
,比如支付场景
Log Buffer
,同时写到os buffer
(其会每秒调用 fsync
将数据刷入磁盘),性能好,安全性也高。这个是实时性适中
一致性适中
的,比如订单类
。
自适应Hash索引
主要用于加快查询 页
。在查询时,Innodb通过监视索引搜索的机制来判断当前查询是否能走Hash索引
。比如LIKE运算符和% 通配符就不能走。
存储在一个叫ibdata1
的文件中,其中包含:
Buffer Pool
写入数据页时,不是直接写入到文件,而是先写入到这个区域。这样做的好处的是,一但操作系统,文件系统或者mysql挂掉,可以直接从这个Buffer
中获取数据。
每一张表都有一张 .ibd
的文件,存储数据和索引。
表复制操作
,这可能会增加表空间占用的磁盘空间量
。此类操作可能需要与表中的数据以及索引一样多的额外空间。该空间不会像每表文件表空间
那样释放回操作系统。
Drop table
的时候会影响性能(除非你自己管理了碎片)
fsync
一次性刷入数据到文件中
文件句柄
, 以提供维持对文件的持续访问
共享表空间
,他可以存储多个表
的数据
每表表空间
小
存储在一个叫 ibtmp1
的文件中。正常情况下Mysql启动的时候会创建临时表空间,停止的时候会删除临时表空间。并且它能够自动扩容。
原子性
,即当修改到一半,出现异常,可以通过Undo 日志回滚。
系统表空间``撤销表空间``临时表空间
中,如架构图所示。
origin
,返给执行器
innodb
引擎没有多大关系,我们前面说的那两种日志,都在是innodb引擎层的。而Bin log
是处于服务层
的。所以他能被各个引擎所通用
Bin log
是以事件的形式,记录了各个 DDL DML
语句,它是一种逻辑意义上的日志。
主从复制
, 从
服务器拿到主
服务器的bin log
日志,然后执行。
数据恢复
,拿到某个时间段的日志,重新执行一遍。
要想彻底弄明白InnoDB中的索引
是个什么东西,就必须要了解它的文件存储级别
所以有时候,我们被要求主键为什么要是有序的原因就是,如果我们在一个有序的字段上,建立索引,然后插入数据。 在存储的时候,innodb就会按着顺序一个个存储到 页
上,存满一个页再去申请新的页,然后接着存。
但如果我们的字段是无序的,存储的位置就会在不同的页上。当我们的数据存储到一个已经被 存满
的页
上时,就会造成页分裂
,从而形成碎片
。
B+树
图所示,子节点上存储行数据
,并且索引的排列的顺序
和索引键值顺序
一致的话就是 聚簇索引
。主键索引就是聚簇索引,除了主键索引,其他所以都是辅助索引
辅助索引
,它的叶子节点上只存储自己的值
和主键索引的值
。这就意味着,如果我们通过辅助索引查询所有数据,就会先去查找辅助索引
中的主键键值
,然后再去主键索引
里面,查到相关数据
。这个过程称为回表
rowid
如果没有主键索引
怎么办呢?
聚簇索引
。
rowid
的东西,根据这个id来创建 聚簇索引
搞清楚什么是索引,结构是什么之后。 我们来看看,什么时候我们要用到索引,理解了这些能更好的帮助我们创建正确高效的索引
离散度低不建索引,也就是数据之间相差不大的就没必要建立索引。(因为建立索引,在查询的时候,innodb大多数据都是相同的,我走索引 和全表没什么差别就会直接全表查询
)。比如 性别字段。这样反而浪费了大量的存储空间。
覆盖索引
。如果我们此次查询的所有数据
全都包含在索引里面了,就不需要再 回表
去查询了。比如:select class_name from stu where name =lzw
索引条件下推
,因为后面是 like '%xx'
的查询条件,所以这里首先根据 name
走 idx联合索引
查询到几条数据后,再回表
查询到全量row数据
,然后在server层
进行 like
引擎层
对like也进行过滤了,相当于把server层
这个过滤操作下推到引擎层
了。如图所示:
页分裂
,索引按顺序存储,如果存储页满了,再去插入就会造成页分裂)
函数
的时候不会使用索引,所以没必要额外建
优化器决定的
。比如你使用了 Cost Base Optimizer
基于开销的优化器,那种开销小就用哪种优化。
先回顾一下我们耳熟能详的几个基本概念:
SQL92 标准规定: (并发度从左到右,依次降低)
这两种方案在Innodb中结合使用。这里简要说明一下 RR 的 MVCC实现
,图中 回滚id 初始值不应该为0而是NULL,这里为了方便写成0
RC的MVCC实现是对 同一个事务的多个读 创建一个版本
而 RR 是 同一个事务任何一条都创建一个版本
通过MVCC
与LBCC
的结合,InnoDB能解决对于不加锁
条件下的 幻读的情况。而不必像 Serializable
一样,必须让事务串行
进行,无任何并发
。
下面我们来深入研究一下InnoDB锁
是如何实现 RR
事务隔离级别的
上面这四把锁
是最基本锁的类型
这三把锁,理解成对于上面四把锁
实现的三种算法方式,我们这里暂且把它们称为:高阶锁
上面三把是额外扩展的锁
打一个标记
,记录这个表是否被锁住了) => 如果没有这个锁,别的事务想锁住这张表的时候,就要去全表扫描是否有锁,效率太低。所以才会有意向锁的存在。
锁的是索引,那么这个时候可能有人要问了:那如果我不创建索引呢?
索引的存在,我们上面讲过了,这里再回顾一下,有下面几种情况
完整的数据
)
聚簇索引
rowid
的东西,根据这个id来创建 聚簇索引
所以一个表里面,必然会存在一个索引,所以锁当然总有索引拿来锁住了。
当要给一张你没有显示创建索引
的表,进行加锁查询
时,数据库其实是不知道到底要查哪些数据的,整张表可能都会用到。所以索性就锁整张表
。
辅助索引
加写锁,比如select * from where name = ’xxx‘ for update
最后要回表
查主键上的信息,所以这个时候除了锁辅助索引
还要锁主键索引
首先上三个概念,有这么一组数据:主键是 1,3,6,9 在存储时候有如下:x 1 x 3 x x 6 x x x 9 x···
首先这三种锁都是 排它锁
, 并且 临键锁 = 记录锁 + 间隙锁
Record Lock 行锁
防止别的事务修改或删除,Gap Lock 间隙锁
防止别的事务新增,Gap Lock 和 Record Lock
结合形成的Next-Key锁
共同解决RR级别
在写数据时的幻读问题。
=> 代理层 -- Mycat(将所有与数据库的连接独立出来。全部由Mycat连接,其他服务访问Mycat获取数据) => 服务层 -- 特殊的SQL版本
说到底我们学习这么多知识都是为了能更好使用MYSQL,那就让我们来实操一下,建立一个完整的优化体系
要想获得更好的查询性能,可以从这张查询执行过程
入手
添加连接池,避免每次都新建、销毁连接
那我们的连接池是不是越多越好呢? 有兴趣的盆友可以看看这篇文章:About Pool Sizing
CPU
才能真正去执行线程
。而操作系统因为用时间分片
的技术,让我们以为一个CPU内核
执行了多个线程
。
CPU
在某个时间段
只能执行一个线程
,所以无论我们怎么增加并发,CPU
还是只能在这个时间段里处理这么多数据。
CPU
处理不了这么多数据,又怎么会变慢?因为时间分片
,当多个线程看起来在"同时执行"
,其实他们之间的上下文切换
十分耗时
I/O
操作,这个时候,CPU
就可以把时间,分片给其他线程
,以提升处理效率和速度
I/O
等待时间非常短,所以我们就不能添加过多连接数
很多CPU计算和I/O的场景
比如:设置最大线程数等
如果并发非常大,就不能让他们全打到数据库上,在客户端连接数据库查询时,添加如Redis
这种三方缓存
既然我们一个数据库承受不了巨大的并发,那为什么不多添加几台机器呢? 主从复制原理图
从图中我们不难看出、Mysql主从复制 读写分离
异步复制
的特性。
上面这种异步
的主从复制,很明显的一个问题就是,更新不及时的问题。当写入一个数据后,马上有用户读取,读取的还是之前的数据,也就是存在着延时。 要解决延时的问题,就需要引入 事务
failover
动作,即主节点挂掉,选举从节点后,能快速自动避免数据丢失。
对数据进行分类划分,分成不同表,减少对单一表造成过多锁操作
影响性能
任何SQL在写完之后都应该explain
一下
left/right join
会直接指定驱动表,在MYSQL中,默认使用Nest loop join
进行表关联(即通过驱动表
的结果集作为循环基础数据,然后通过此集合中的每一条数据筛选下一个关联表的数据,最后合并结果,得出我们常说的临时表
)。
驱动表
的数据是 百万千万
级别的,可想而知这联表查询得有多慢。但是反过来,如果以小表
作为驱动表
,借助千万级表
的索引
查询就能变得很快。
驱动表
,那么请交给优化器来决定,比如:select xxx from table1, table2, table3 where ···
,优化器会将查询记录行数少的表作为驱动表。
驱动表
,那么请拿好Explain
武器,在Explain
的结果中,第一个就是基础驱动表
表
排序也是有很大的性能差异,我们尽量对驱动表
进行排序,而不要对临时表,也就是合并后的结果集
进行排序。即执行计划中出现了 using temporary
,就需要进行优化。
普通查询
和复杂查询
(联合查询、子查询等)
PRIMARY
,如果查询包含复杂查询
的子结构,那么就需要用到主键查询
越来越快
const或者system
常量级别的扫描,查询表最快的一种,system是const的一种特殊情况(表中只有一条数据)
ref
非唯一性索引扫描
NULL
,不需要访问表或者索引
不一定使用
哪一个索引被真正使用
到了。如果没有则为NULL
索引(key)
一起被使用
only index
信息只需要从索引中查出,可能用到了覆盖索引,查询非常快
using where
如果查询没有使用索引,这里会在server
层过滤再使用 where
来过滤结果集
using filesort
,只要没有通过索引来排序,而是使用了其他排序的方式就是 filesort
using temporary
(需要通过临时表来对结果集进行暂时存储,然后再进行计算。)一般来说这种情况都是进行了DISTINCT、排序、分组
插入与查询
比较多的时候,可以使用MyISAM
存储引擎
memory
插入、更新、查询
等并发数很多时,可以使用InnoDB
从五个层次回答MYSQL优化,由上至下
除此之外,查数据慢,要不仅仅拘留于一味的 "优化" 数据库,而是要从业务应用层面去分析。比如对数据进行缓存,对请求进行限流等。
相关免费学习推荐:mysql视频教程
以上就是一篇文章让你搞懂MYSQL底层原理的详细内容,更多请关注gxlcms其它相关文章!
从事设计,最怕修改,更怕的是,推倒重来。
改图是设计师的日常工作,相信大家处理起来驾轻就熟。
但如果遇到这种状况,想必你也是束手无策了吧?
拿三维设计来说,如果基于第三方文件对复杂模型细节进行修改,是相当困难的。
因为大家都知道,传统三维设计是通过参数化建模完成的,这就涉及到模型数据的约束和同步,这无疑是一个巨大的挑战。
想要修改某个零件的圆角,需要花不少时间在历史树中查找该零件的特征,此外,为了防止不破坏模型,你还得全面了解模型的构建方式......
如何摆脱困境,中望3D 2020提供的直接编辑功能就属于无历史树建模技术,能够有效解决参数化建模带来的诸多不便,让你能够直接对模型数据进行后编辑,下面我们来详细了解一下。
相当完美的植入,文末开奖,有你的名字吗?
中望3D直接编辑功能支持设计师直接编辑现有的3D模型。
无论模型是从外部接收到的由其他CAD软件创建而来,还是在中望3D中创建的,即使没有历史树记录,设计师也可以在不清楚模型构建过程的情况下,对模型进行任意修改或者在其上面创建新的几何图形。
没有历史树记录也可直接编辑模型
大家在修改模型时,中望3D会自动识别并维护其现有的约束关系,即使该模型没有历史树。
例如,当你编辑下图模型上的内孔时,软件可以自动识别其与外圆的同心约束,从而将外圆也一起移动,实现两者相对位置关系不变。
修改时保持模型的原始约束关系
模型被修改之后,中望3D会自动生成新的历史树,从而为你在后续参数化模式下的修改编辑提供精确的工程数据。
值得一提的是,中望3D不但提供了直接编辑功能,同时还保留了修改过程,让大家可通过直接编辑或历史树重新编辑修改。
动态预览直观地编辑模型
中望3D 2020的直接编辑功能提供了两种修改特征的方法,大家可在对话框中输入具体的数值,也可以直接拖动几何图形以获取所需的结果。
在中望3D中编辑模型时,修改和相关约束会实时更新,你可以预览模型动态,从而更直观地更改模型。
动态预览直观地修改模型
多种编辑工具,可精确控制尺寸
中望3D 2020的直接编辑功能提供了多种编辑工具,可精确控制尺寸。
你可以选择DE移动、对齐移动面、通过标注移动面等不同的命令来修改模型。
此外,你也可以在每个操作中输入精确值以控制几何数据,从而更灵活地编辑模型,同时确保建模的准确性。
使用直接编辑时精确控制尺寸
竞速赛:寻找隐藏的中望3D 2020新增功能
前五名:时针 、 晟晟`Γατнεг 、 啊哈 、 David 、 欧阳丶晓枫残月 获得中望3D 2020版180天激活码
请以上10位小伙伴于工作日的工作时间在微信公众号对话框私聊望Sir领码。