深入浅出MySQL系列(1)—MySQL的基础架构分析

最新推荐文章于 2024-07-25 11:20:42 发布

小李子i

最新推荐文章于 2024-07-25 11:20:42 发布

阅读量40

点赞数

分类专栏： MySQL 文章标签： mysql 数据库

本文链接：https://blog.csdn.net/li2683056515/article/details/132048803

版权

MySQL 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

MySQL的逻辑架构

MySQL 由三层组成：

连接层：客户端和服务器端建立连接，客户端发送 SQL 至服务器端；
SQL 层：对 SQL 语句进行查询处理；
存储引擎层：与数据库文件打交道，负责数据的存储和读取。

更细化的MySQL基本架构示意图： 一条SQL查询语句是如何执行的？

一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等功能模块，最后到达存储引擎。

MySQL 可以分为 Server 层和存储引擎层两部分

Server 层： 包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。
存储引擎层： 负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。（InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎）

一些常见的存储引擎：

①InnoDB 存储引擎：它是 MySQL 5.5 版本之后默认的存储引擎，最大的特点是支持事务、行级锁定、外键约束等。

②MyISAM 存储引擎：在 MySQL 5.5 版本之前是默认的存储引擎，不支持事务，也不支持外键，最大的特点是速度快，占用资源少。

特点：崩溃后无法恢复；设计简单、数据以紧密格式存储，所以在某些场景下的性能很好；

③Memory 存储引擎：使用系统内存作为存储介质，以便得到更快的响应速度。不过如果 mysqld 进程崩溃，则会导致所有的数据丢失，因此我们只有当数据是临时的情况下才使用 Memory 存储引擎。

④NDB 存储引擎：也叫做 NDB Cluster 存储引擎，主要用于 MySQL Cluster 分布式集群环境，类似于 Oracle 的 RAC 集群。

⑤Archive 存储引擎：它有很好的压缩机制，用于文件归档，在请求写入时会进行压缩，所以也经常用来做仓库。只支持INSERT和SELECT操作；

存储引擎的选择：

一般就建议选InnoDB

只读或者读业务多的，或许可以选择MyISAM 存储引

1）连接器

连接器负责跟客户端建立连接、获取权限、维持和管理连接。

长连接：指连接成功后，如果客户端持续有请求，则一直使用同一个连接。
短连接：指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。

因为建立连接的过程通常是比较复杂，所以尽量使用长连接。

但全部使用长连接后存在一个问题：有些时候 MySQL 占用内存涨得特别快？这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如果长连接累积下来，==可能导致内存占用太大。

解决办法：

①定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。

②如果用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

2）查询缓存

MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式，被直接缓存在内存中。key 是查询的语句，value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接返回给客户端。

但是如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。可以看到，如果查询缓存命中的话，这个查询效率是很快的！！

但是，大多数情况下还是不要使用查询缓存！因为查询缓存往往弊大于利！

原因： 查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能我们费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。