Mysql - 架构及常用组件功能

Mysql - 架构及常用组件功能,第1张

mysql底层架构分为:

1、client(客户端)

2、server(服务端)

client: 主要有各种plugin、jdbc等

server: 包含了连接器、查询缓存、分析器、优化器、执行器、存储引擎

连接器 的主要作用是与 客户端 建立联系,管理客户端的连接、会话、权限验证等。

查询缓存 的作用是,在sql通过连接器之后到达服务端之后,如果sql是sel开头的语句,那么先在 查询缓存 中获取命中结果,如果有命中结果则直接返回结果。没有结果那么sql会通往 分析器 。

分析器 拿到sql后,会对sql进行词法、语法分析,同时创建sql Id,如果sql有错误,那么将会终止sql行为,将异常返回客户端。

优化器 的作用主要是对通过 分析器 的sql进行优化,比如进行 索引选择 、 重写查询 等,同时会创建 sql执行计划 ,可以通过 explain 指令进行查看。

执行器 拿到了经过优化器的sql,将会 *** 作 存储引擎 ,通过调用 存储引擎 提供的读写接口,得到返回结果。

存储引擎 是sql的最终执行者,它对外提供了读写接口,本身主要作用为执行sql、存储数据、获取数据等, 存储引擎 的设计是插件形式实现的,常见了有 InnoDB 、 MyISAM 等。

未完待续......

阿里巴巴开发手册中指出:

【强制】在表查询中,一律不要使用 * 作为查询的字段列表,需要哪些字段必须明确写明

说明:

首先介绍一下MySQL基本架构,基本结构如下图:

MySQL 基本架构可以分为 Server 层和存储引擎层两部分。Server 层包括连接器、查询缓存、分析器、优化器、执行器等。存储引擎层负责数据的存储和提取,其架构模式是插件式的,支持 InnoDB、MyISAM、Memory 等多个存储引擎

当我们执行一条查询语句:select * from t where id = 1,在MySQL中执行过程如下:

假设有一条sql语句为select * from t where name = "何甜甜",其中id为主键,name为索引,而实际上这么写的目的只是想查询指定name的id

在innodb存储引擎中,索引可以分为非主键索引和主键索引,主键索引和主键的区别在于叶子节点存放数据的不同。主键索引中叶子节点存放的是整行数据,而非主键索引中叶子节点存放的是主键的值。现在我们来看select * from t where name = "何甜甜"这条语句是如何执行的

因为name是索引且name是查询条件,查询优化器会选择使用name索引。首先根据name查询到该name对应的主键id为1,因为需要查询的是指定name的所有数据,因此还需要根据主键id进行一次 回表 *** 作。所谓回表 *** 作是指非主键索引中查询到主键id,在根据主键id到主键索引中查询到所有数据,具体过程可看下图

前面已经提到查询到的 中只是用到了id字段,如果将原来的sql语句修改为select id from t where name = "何甜甜",就可以避免一次回表 *** 作。在非主键索引中已经覆盖了查询需求【即所需查询的ID已在非主键索引上了】,也被称为 覆盖索引 *。通过覆盖索引可以减少回表次数,从而显著提升查询性能,因此在实际写sql过程中应该尽量避免写select * 这样的查询语句,写之前先反问是否真的需要用到这么多字段

BLOB和TEXT是为了存储很大的数据而设计的字符串数据类型,当BLOB和TEXT值太大时,InnoDB会使用专门的外部存储区域来进行存储,每个值在行内需要1~4字节存储一个指针,然后在外部存储区域存储实际的值,如果查询的*中有BLOB或TEXT类型的字段,则查询的BLOB或TEXT列需要在进行额外一次IO *** 作去外部存储区域将数据查询到,所以尽量避免使用select *

传输数据过多会增加网络开销。同时,查询语句执行时会先将查询到的数据放到查询缓存区中,再从查询缓存中将结果返回给客户端,如果查询到的数据量非常大则需要花很多时间来存储结果,所以在说一次,避免使用select *

在实际开发中应尽量避免写select *这样的SQL语句,虽然通常情况下即使真的写了这样的select *这样的SQL语句,对项目的影响可能也没这么大,但好习惯还是要养成的

我还是觉得之前写的文章也很不错, 用户管理模块:如何保证用户数据安全 ,还是要再继续宣传一波,点个赞在走吧

服务器架构随着应用场景的不同采用的架构方式也是不一样的,而今天我们就通过案例分析来简单学习一下,在服务器架构中的可扩展性都有哪些特点。

MySQL的可扩展性架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展性的架构,这里对可扩展性进行简单介绍一下,常用的扩展手段有以下两种Scale-up:纵向扩展,通过替换为更好的机器和资源来实现伸缩,提升服务能力Scale-out:横向扩展,通过加节点(机器)来实现伸缩,提升服务能力对于互联网的高并发应用来说,无疑Scaleout才是出路,通过纵向的买更的机器一直是我们所避讳的问题,也不是长久之计,在scaleout的理论下,可扩展性的理想状态是什么?可扩展性的理想状态一个服务,当面临更高的并发的时候,能够通过简单增加机器来提升服务支撑的并发度,且增加机器过程中对线上服务无影响(nodowntime),这就是可扩展性的理想状态!MySQL架构的演变MySQL简单网站架构(V1.0)一个简单的小型网站或者应用背后的架构可以非常简单,数据存储只需要一个mysqlinstance就能满足数据读取和写入需求(这里忽略掉了数据备份的实例),处于这个时间段的网站,一般会把所有的信息存到一个databaseinstance里面。

在这样的架构下,电脑培训http://www.kmbdqn.cn/来看看数据存储的瓶颈是什么?单实例单业务,依然存在V1.0所述瓶颈,遇到瓶颈时可以考虑往本文更高V版本升级,若是读请求导致达到性能瓶颈可以考虑往V3.0升级,其他瓶颈考虑往V4.0升级


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/7221736.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-03
下一篇 2023-04-03

发表评论

登录后才能评论

评论列表(0条)

保存