MySQL逻辑架构

MySQL逻辑架构

服务器处理客户端请求的处理流程

逻辑架构图

由上图可以大致划分为连接层、服务层和引擎层

MySQL逻辑架构由以下组件组成：

Connectors
指的是不同语言中与SQL的交互，如php、java等。

Management Serveices & Utilities：
系统管理和控制工具

Connection Pool: 连接池
管理缓冲用户连接，线程处理等需要缓存的需求。

SQL Interface: SQL接口

• 接收用户的SQL命令，并且返回用户需要查询的结果。比如SELECT … FROM就是调用SQL
  Interface
• MySQL支持DML（数据操作语言）、DDL（数据定义语言）、存储过程、视图、触发器、自定
  义函数等多种SQL语言接口

Parser: 解析器（生成解析树）

• 在解析器中对 SQL 语句进行语法分析、语义分析。将SQL语句分解成数据结构，并将这个结构
  传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的。如果在分解构成中遇到错
  误，那么就说明这个SQL语句是不合理的。
• 在SQL命令传递到解析器的时候会被解析器验证和解析，并为其创建语法树，并根据数据字
  典丰富查询语法树，会验证该客户端是否具有执行该查询的权限。创建好语法树后，MySQL还
  会对SQL查询进行语法上的优化，进行查询重写。

Optimizer: 查询优化器（生成一个执行计划）

• SQL语句在语法解析之后、查询之前会使用查询优化器确定 SQL 语句的执行路径，生成一个执行计划。

• 这个执行计划表明应该使用哪些索引进行查询（全表检索还是使用索引检索），表之间的连接顺序如何，最后会按照执行计划中的步骤调用存储引擎提供的方法来真正的执行查询，并将查询结果返回给用户。

• 使用“选取-投影-连接”策略进行查询。例如：

  用一个例子就可以理解： select uid,name from user where gender = 1;

  这个select 查询先根据where 语句进行选取，而不是先将表全部查询出来以后再进行gender过滤。这个select查询先根据uid和name进行属性投影，而不是将属性全部取出以后再进行过滤。将这两个查询条件联接起来生成最终查询结果

Caches & Buffers： 查询缓存组件

• MySQL内部维持着一些Cache和Buffer，比如Query Cache用来缓存一条SELECT语句的执行结果，如果能够在其中找到对应的查询结果，那么就不必再进行查询解析、优化和执行的整个过程了，直接将结果反馈给客户端。在读写比例非常高的应用系统中， Query Cache 对性能的提高是非常显著的。当然它对内存的消耗也是非常大的。

• 这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等 。

• 从MySQL 5.7.20开始，不推荐使用查询缓存，并在MySQL 8.0中删除。

  弃用查询缓存的原因

  • 走查询缓存返回结果的要求太苛刻，要求走cache 是指select 语句一毛一样

  • 查询缓存的实现可能导致在高并发情况下频繁的锁竞争，影响整体数据库性能

    在MySQL的查询缓存中，锁的粒度问题主要体现在查询缓存的实现方式上。当查询缓存开启时，如果对一张表进行写操作（比如插入、更新、删除），整个表的查询缓存将被失效，这可能导致锁住整个表而不是仅仅影响到那些被修改的部分。

    这就意味着即使只有很小一部分数据被修改，整个表的查询缓存都会失效，而其他查询也会被阻塞等待缓存失效后的刷新。这种锁定方式会对数据库的并发性能产生负面影响，尤其是在高并发环境中，可能会造成大量的阻塞，降低数据库的响应速度。

    https://blog.csdn.net/m0_54187478/article/details/134226981

buffer与cache的区别？
缓存那里实际上有buffer和cache两个，那它们之间是否有什么不同呢？简单的说就是，buffer是写缓存，cache是读缓存。

Storage Engines：存储引擎接口

真正的负责了MySQL中数据的存储和提取，对物理服务器级别维护的底层数据执行操作 ，服务器通过API与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取。 注意：存储引擎是基于表的，而不是数据库。