Mysql底层剖析——Mysql逻辑架构与执行流程

本文详细介绍了MySQL的三层逻辑架构,包括连接处理、查询解析、优化与执行等关键步骤。在查询过程中,MySQL首先检查查询缓存,然后进行语法解析和预处理,接着由查询优化器选择最佳执行计划。同时,文章还涵盖了连接管理和安全性,以及存储引擎的角色。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、Mysql逻辑架构

在这里插入图片描述

1、第一层

        主要负责连接处理、授权认证、安全

2、第二层

        负责查询、解析、优化、缓存以及所有内置函数,所有跨存储引擎的功能都在这一层实现:存储过程、触发器、视图等。

3、第三层

        包含存储引擎,存储引擎负责MySQL中数据的存储和提取,服务器通过API与存储引擎进行通信,这些接口屏蔽了不同引擎的差异。存储引擎API包含几十个一层函数,例如开启事务函数等。不同存储引擎相互隔离,不会通信,主要的作用是响应上层服务器的请求。

二、MySQL执行流程

在这里插入图片描述

1、查询缓存

        在解析一个查询语句之前,如果查询缓存是打开的,那么MySQL会优先检查这个查询是否命中查询缓存中的数据,这个检查是通过一个对大小写敏感的哈希查找来实现的,只要有一个字节不同,就不会匹配缓存结果,这种情况就会进入下一阶段的处理。、
        如果当前的查询恰好命中了查询缓存,那么在返回查询结果之前MySQL会检查一次用户权限。这是无须解析查询SQL语句的,因为在查询缓存中已经存放了存放了当前查询需要访问的表新信息,如果权限没有问题,MySQL会跳过所有其他阶段,直接拿到结果并返回给客户端,查询不会被解析,不用生存执行计划,不会被执行。

2、语法解析器和预处理

        首先,mySQL通过关键字将SQL语句进行解析,并生成一颗对应的解析树,MySQL解析器将使用MySQL语法规则验证和解析查询MySQL语法规则和解析查询验证是否使用错误的关键字,及关键字的顺序是否正确等。
        预处理器则根据一些MySQL规则进一步检查解析树是否合法,例如将检查数据表和数据列是否存在,还会解析名字和别名。

3、查询优化器

        到了查询优化器语法树就会被认为是合法的,并且由优化器转化成执行计划,一条查询可以有很多种执行方式,最后都返回了相同的结果,优化器的作用就是找到这其中最好的执行计划。使用基于成本的优化器。

优化策略包括静态优化和动态优化

静态优化可以直接对解析树进行分析,并万和城那个优化,静态优化在第一次完成后就一直有效,可以认为是编译时优化。

动态优化则和查询的上下文有关,每次执行时都需要重新评估。
https://blog.csdn.net/weixin_42353053/article/details/113224543?

4、连接管理与安全性

        一个客户端连接只会拥有一个线程,这个连接的查询都会在这个线程执行,是由服务器自行创建的。

5、优化与执行

        MySQL会解析查询,并创建解析树,解析树可以重写查询,决定表的读取顺序,选择合适的索引对查询语句进行优化。用户可以通过特殊的关键字来提示优化器,影响它的决策过程,也可以请求优化器解释优化过程的各个因素。存储引擎对优化有影响,优化器会请求存储引擎提供容量或某个具体的开销信息,以及表的统计信息。对于select语句,解析查询前,服务器会先检查查询缓存,如果能在其中找到需要的数据,就直接返回,不会执行查询解析、优化和执行的整个过程。

### MySQL 执行流程及其日志组件间的关系 #### MySQL执行流程 MySQL 处理查询的过程可以分为几个阶段,这些阶段涵盖了从客户端请求到达服务器直到最终响应返回的全过程。以下是典型的 SQL 查询执行路径: 1. 客户端发送一条 SQL 语句到服务端。 2. 服务端接收到该命令后进入连接器部分验证用户权限并建立会话上下文环境。 3. 接下来由分析器负责语法解析语义校验工作,确认输入合法之后构建抽象语法树(AST)[^5]。 4. 经过优化器评估多种可能计划方案选出成本最低的那个作为实际运行路线图[^6]。 5. 缓存子系统尝试检索是否存在匹配项来加速重复调用场景下的反馈速度;如果没有命中则继续往下推进。 6. 存储引擎加载指定表元数据信息准备参后续动作实施环节——对于 InnoDB 类型而言意味着启动事务机制同时锁定相应资源防止冲突发生。 7. 数据访问层依据既定规划逐条扫描符合条件的目标记录集合完成增删改查类基本操作。 8. 结果集组装完毕传递回前端显示界面供使用者查阅。 在整个过程中涉及到多个重要概念和技术细节,下面重点探讨关于 `Log Buffer`、`Redo Log` 及 `Undo Log` 如何协作保障 ACID 特性实现高效可靠的数据管理解决方案。 --- #### Log Buffer、Redo Log 和 Undo Log 的定义及作用 ##### Log Buffer 这是位于内存中的缓冲区,专门用于存储待写入磁盘的 Redo Logs 。每次事务提交时产生的新日志不会立刻被写出硬盘而是优先放入此区域等待适当机会统一处理减少 IO 开销提升整体效率水平 [^3]. ##### Redo Log (重做日志) 它是基于 Write-Ahead Logging(WAL) 原则设计出来的物理级变更追踪工具,在任何修改真实落地之前都会提前记录相关变动描述形成永久副本保存起来方便应对突发状况比如断电重启等情况下的快速恢复需求 [^1]. ##### Undo Log (撤销日志) 相比之下更偏向逻辑层面的操作跟踪体系,主要服务于两个目的:一是允许未成功结束的任务撤消已完成的部分回到初始状态;二是辅助 Multi-Version Concurrency Control(MVCC),即让不同时间点发起读取活动的人看到各自对应版本的内容而不互相干扰 [^4]. --- #### 关联性说明 - **Log Buffer vs Redo Log** - 当应用程序向数据库发出 COMMIT 请求时,相应的改动首先会被追加至 Log Buffer ,稍后再经由后台进程逐步迁移到真正的 Redo Log 文件里头去长期留存备用 [^3]. - **Redo Log vs Undo Log** - 虽然二者同属 InnoDB 架构内部不可或缺的关键组成部分却承担完全不一样的职责使命 ——前者聚焦未来可能出现的风险防范措施制定预案后者则是围绕当前正在进行的工作流提供必要的安全保障手段确保一切按照预期顺利开展下去 [^4][^1]. - **综合视角来看** - 整套架构通过巧妙结合以上三种要素实现了高度自动化的错误检测修复能力以及灵活可扩展的应用开发框架支持开发者专注于业务逻辑本身无需过多顾虑底层复杂度带来的困扰 [^2]. --- ```sql -- 示例代码片段展示如何查看有关 redo log 设置的信息 SHOW VARIABLES LIKE 'innodb_log%'; -- 获取 undo 表空间详情 SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME LIKE '%undo%'; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值