当前位置： 首页 > news >正文

【MySQL进阶】MySQL架构

news 2025/7/7 16:47:12

目录

一. 什么是MySQL架构

二. 连接层

2.1. 网络端口

2.2. 连接管理线程

2.3.客户端连接线程管理

2.4.连接量管理

三. 服务层

3.1 服务管理和公共组件

3.2 NoSQL接口与SQL接口

3.3 Parser(语法分析器)

3.4 Optimizer(查询优化器)

3.5 Caches & Buffers(缓存)

3.6 SQL语句的执行流程

 

一. 什么是MySQL架构

MySQL8.0服务器是由连接池、服务管理⼯具和公共组件、NoSQL接⼝、SQL接⼝、解析器、优化 器、缓存、存储引擎、⽂件系统组成。

MySQL还为各种编程语⾔提供了⼀套⽤于外部程序访问服务器 的连接器。整体架构图如下所⽰：

MySQL直接讲其实很复制，我们还是举例来说明比较好。 

我们用餐厅聚餐的例子，一步步对应MySQL的架构图：

  1. 抵达餐厅 & 连接层 (Connection Pool)

    • 我们（客户方）：相当于应用程序（.NET, Python, PHP等）或MySQL Shell。

    • 餐厅地址：相当于MySQL服务器的IP地址和端口号。

    • 迎宾员：核心就是MySQL的连接层/连接池。

      • 确认人数/空闲座位（连接池）：迎宾员知道餐厅有多少桌子（最大连接数 max_connections），哪些是空的（空闲连接）。他会查看是否有足够的空位容纳我们（检查 max_connections 和当前连接数），如果没有足够的空位，就会让我们来排号。

      • 带位/安排服务员（线程复用）：迎宾员安排我们入座，并指定一位服务员（数据库线程）为我们服务。如果服务员刚服务完上一桌且桌子没换（连接空闲时间在 wait_timeout 内），这位服务员可以立刻为我们服务（线程复用）。如果需要新的服务员，迎宾员会通知后厨调度（服务层）分配一位（创建新线程）。

      • 身份确认（Authentication）：迎宾员可能会确认我们的预订信息或询问是否有会员（用户名/密码认证）。

      • 检查预订信息/特殊要求（Check Memory & Caches）：迎宾员可能会快速翻看记录本（部分缓存）看看我们是否有特殊要求（部分连接上下文信息）。

    • 结果：我们成功“连接”到餐厅，拥有了专属的“会话”（连接）和服务员（线程）。

  2. 点餐与服务：服务层 (Service Layer & Management)

    • 服务员 (SQL Interface / NoSQL Interface)：我们落座后，负责我们这桌的服务员来了。他/她：

      • 递菜单、听需求（SQL/NoSQL Interface）：服务员提供菜单（SQL命令集或文档模型）。我们告诉服务员想吃什么（SELECT 查询），想加什么菜（INSERT），想换掉什么菜（UPDATE），或者退掉某个菜（DELETE）。如果我们用特定的语言说“老样子”（相当于NoSQL的API调用），服务员也能理解（如果餐厅支持）。

      • 理解复杂需求（Parser）：如果我们点了一个复杂的套餐，或者要求“不要辣，但其中那个宫保鸡丁要微辣”（一个复杂的带条件和子查询的SQL），服务员需要准确理解每一个细节（语法解析、语义检查），并确认我们是否有权限点这道菜（Object Privilege Check）。

      • 规划上菜顺序/协调后厨（Optimizer）：服务员拿到订单后，不会直接扔给后厨。他/她需要思考：

        • 哪些菜可以一起做（多表连接顺序优化）？

        • 哪些菜做起来快，先上（索引扫描 vs 全表扫描）？

        • 海鲜区现在忙不忙，要不要让炒菜区先做别的（基于统计信息 statistics 选择访问路径）？

        • 有没有现成的凉菜可以直接上（缓存命中）？
          这个过程就是查询优化器 (Optimizer) 在计算最优的“执行计划”。

    • 后厨调度（Caches & Buffers）：服务员（或传菜员）会先去“出菜口”（缓存区）看看：

      • 热菜保温区（Global Caches）：有没有其他桌点了相同的菜还没上完，正好有多一份（Query Cache - 注：MySQL 8.0已移除Query Cache，但Buffer Pool等仍是核心缓存）

      • 常用食材备料区（Buffer Pool）：炒菜需要的肉片、蔬菜是不是已经洗好切好放在灶台边了（数据页缓存）？还是需要去冷库（磁盘）现取？

    • 餐厅经理（Service Management & Utilities）：在餐厅运营的后台，还有管理人员负责：

      • 备菜与恢复（Backup & Recovery）：每天打烊后备份所有食材清单和秘方（备份），万一厨房失火（服务器宕机），能按备份重建厨房和菜单（恢复）。

      • 安保（Security）：检查后门锁好没（网络安全），监控谁进了厨房（权限管理），防止食材被偷（数据安全）。

      • 开分店（Replication）：生意太好开了分店（主从复制），主店的菜单更新（数据变更）要同步到分店。

      • 连锁管理（Cluster）：开了好几家店形成连锁（如InnoDB Cluster），需要协调各店库存和订单（分布式一致性）。

      • 分区管理（Partitioning）：把超大的海鲜池分成几个区域（表分区），分别放鱼、虾、蟹，方便管理和快速取用。

      • 管理工具（Instance Manager, Admin, Migration）：餐厅使用的点餐系统管理后台、供应商切换工具等。

  3. 烹饪执行：存储引擎层 (Storage Engines)

    • 后厨分区 & 厨师团队（可插拔存储引擎）：服务员把优化好的订单（执行计划）交给后厨。后厨不是铁板一块，它被划分为不同的工作区，每个工作区由不同的厨师团队负责，他们擅长不同的烹饪方式和食材管理：

      • 热炒区 - InnoDB团队：主力团队，负责大部分热菜（核心事务型数据）。

        • 特点：支持现炒现上（事务ACID），保证菜要么全上齐要么全不上（原子性），炒菜过程隔离（隔离性），炒完必须能上桌（持久性）。食材（数据）摆放有序（聚簇索引），找起来快。支持外卖订单（并发高）。有专门的“暂存台”（Undo Log）处理退菜（回滚），有“订单流水单”（Redo Log）保证即使灶台着火（宕机）也能知道哪些菜没做完。

      • 凉菜/烧烤区 - MyISAM团队：以前的主力，现在主要负责一些简单凉菜或烧烤（读多写少的历史数据/临时报表）。

        • 特点：出菜（读）非常快。但一次只能专心做一份订单（表级锁），加个香菜（改一点数据）也要锁整个桌子。不太在乎菜没上齐（不支持事务）。如果停电（崩溃），恢复起来比较麻烦。

      • 即食区 - MEMORY团队：负责需要瞬间上桌的小菜，比如拍黄瓜、花生米（临时表、超快缓存）。

        • 特点：闪电速度（内存存储）。但打烊（重启）就全扔了（非持久化）。

      • 罐头/预包装区 - ARCHIVE团队：负责储存大量的腌菜、干货（归档数据）。

        • 特点：非常节省空间（高压缩），但只能往里存（只支持INSERT/SELECT），拿出来加工（修改/删除）很麻烦。

      • 垃圾桶 - BLACKHOLE团队：负责处理一些特殊订单，比如“试菜”（测试复制），或者不需要实际出菜的指令。

        • 特点：接订单（收数据），但直接扔掉（不存储），假装完成了。

      • 外包窗口 - FEDERATED团队：如果顾客点的特色菜本店不做，但隔壁店有，这个团队负责去隔壁店点（访问其他MySQL服务器的表）。

      • 其它团队：MERGE (合并几个MyISAM桌)，CSV (用Excel管理食材清单)，EXAMPLE (展示怎么开新分区)。

    • 厨师长协调（MySQL Server 与引擎接口）：MySQL服务器核心（服务层）就是总厨师长。他定义好订单格式（执行计划API），各个厨师团队（存储引擎）按照这个格式去执行具体的烹饪（数据读写）。总厨师长不关心团队内部怎么炒菜（物理存储格式），只关心结果（返回数据行）。

  4. 食材存取：文件系统层 (Files & Logs)

    • 冷库、货架、记录本（文件系统）：所有食材（数据）的最终存放地，以及餐厅运营的记录。

      • 食材仓库（Data Files）：冷库里分门别类存放的各种食材（.ibd文件 for InnoDB, .MYD/.MYI for MyISAM）。货架上的标签就是索引（Index Files）。

      • 采购 & 加工日志（Log Files）：

        • 订单流水单（Redo Log）：InnoDB团队专用。记录每一份订单的关键步骤（物理变更）。万一灶台着火（宕机），靠这个流水单就能知道哪些菜做到哪一步了，重新开火后能接着做完。

        • 退菜单（Undo Log）：InnoDB团队专用。记录如何撤销一份订单（回滚操作），或者给老顾客看之前的订单（一致性读）。

        • 监控录像（Binary Log）：餐厅经理（复制/备份）用。记录所有成功下单的订单（逻辑变更）。用于：

          • 开分店：把主店的录像给分店看（复制）。

          • 灾难恢复：按录像重新采购和做菜（Point-in-Time Recovery）。

        • 意见簿（Error Log）：记录顾客投诉、设备故障（服务器启动、运行、关闭过程中的错误、警告信息）。

        • 服务员工作笔记（General Query Log / Slow Query Log）：记录每个服务员（连接）做的所有事（所有查询），或者哪些菜做的时间特别长（慢查询）。

        • 装修记录（DDL Log）：记录餐厅布局的改变，比如新加了一个工作台（表结构变更）。

    • 厨房设备 & 菜谱（系统文件）：餐厅本身的锅碗瓢盆（MySQL服务器程序、客户端工具如mysql, mysqldump）、秘方（配置文件 my.cnf）等。

总结这次聚餐之旅：

  1. 我们（应用程序） 决定去 XX餐厅（MySQL服务器地址） 吃饭。

  2. 迎宾员（连接层/连接池） 确认我们有位置（连接可用），安排 服务员（线程） 接待我们，并检查预订（认证）。

  3. 服务员（SQL Interface） 接收我们的 点餐请求（SQL命令），理解复杂要求（Parser），并规划最佳上菜顺序（Optimizer）。他/她先看看 出菜口（缓存） 有没有现成的。

  4. 订单送到 后厨（存储引擎层），由 特定的厨师团队（InnoDB, MyISAM等） 根据总厨（MySQL Server核心）的要求执行烹饪（读写数据）。不同团队有专长。

  5. 厨师团队从 冷库货架（数据文件） 取食材，并在 流水单（Redo Log）、退菜单（Undo Log） 上记录操作。

  6. 餐厅 经理（服务管理组件） 负责备份秘方（Backup）、安保（Security）、开分店协调（Replication/Cluster）等后台工作。

  7. 整个餐厅的运营过程被 监控录像（Binary Log） 记录，用于分店同步和灾难恢复。问题和慢操作记在 意见簿（Error Log / Slow Query Log）。

  8. 菜（结果集）最终由服务员端给我们。

这个类比展示了MySQL如何像一个高效协作的餐厅一样，处理来自各种应用程序的“用餐请求”（数据库请求），从建立连接到执行查询、管理数据、保证安全和可靠性，最终返回结果。每一层都有其明确的职责和协作方式。

  • MySQL Connectors：为使⽤MySQL服务的编程语⾔平台，提供了访问接⼝，可以根据⾃⼰实际 使⽤的编程语⾔到官⽹下载地址下载。

官网：MySQL :: MySQL Community Downloads

 

  •  MySQL Shell：是⼀个⾼级客⼾端和代码编辑器，以组件的形式提供，需要单独安装。除了提供的 类似于 mysql 客⼾端的功能，还可以使⽤JavaScript和Python调⽤MySQL的API，⼀般为MySQL数据库开发⼈员使⽤。
  • 连接层：对客⼾端连接进⾏权限校验并保存客⼾端的连接信息，通过池化技术实现线程重⽤，以及 根据具体的配置限制连接数量。
  • 服务管理和公共组件：提供了数据备份与恢复，安全组件，主从复制和集群管理，表分区等实⽤功 能。
  • 服务层：提供了NoSQL API， SQLAPI，SQL语句解析，SQL语句优化，SQL语句缓存等组件，并将优 化后的SQL语句发送⾄存储引擎执⾏相应的操作并返回结果。
  • 存储引擎层：⼀系列可插拔（可动态安装与卸载）的存储引擎，主要负责数据的写⼊和读取，与底层的数据和⽇志⽂件进 ⾏交互，可以根据具体的业务需求选择不同的存储引擎，后⾯我们具体介绍他们之间的区别。
  • ⽂件系统层：包含了MySQL发⾏版的⽂件和程序，以及具体数据库⽂件和⽇志。

接下来我们介绍各层级在整个MySQL服务器中实现的功能。

二. 连接层

MySQL 的连接层（Connection Layer）是客户端与数据库服务交互的第一道关卡，相当于餐厅的 “迎宾台+调度中心”。它的核心作用可以用三个关键词概括：连接管理、权限控制、资源优化。以下是通俗详解：

1. 连接管理：像餐厅的“排队叫号系统”

  • 问题：成千上万人同时要进餐厅（高并发请求），餐厅座位有限（服务器资源有限）。

  • 连接层如何做：

    • ✅ 控制人流量：通过 max_connections 参数（默认151）限制同时就餐人数（并发连接数），超出时拒绝新客人（报 Too many connections 错误）。

    • ✅ 分配服务员：为每个连接分配一个“服务员”（线程），处理客户请求。

    • ✅ 超时清理：如果客人占座不点菜（空闲连接），超过 wait_timeout（默认8小时）自动“请走”（断开连接）。

2. 权限控制：像门口的“安检机”

  • 问题：如何防止陌生人混进厨房（非法访问数据）？

  • 连接层如何做：

    • 🔒 身份核验：检查用户名、密码是否正确（Authentication）。

    • 🚦 权限检查：验证用户是否有权限访问某个数据库（如：禁止实习生查看工资表）。

    • 💡 支持多种认证方式：除密码外，还可搭配SSL证书、LDAP（企业账号）等加强安全。

3. 资源优化：像“服务员复用机制”

  • 问题：为每个客人培训新服务员（创建线程）成本高（消耗CPU/内存）！

  • 连接层如何做：

    • 🔄 线程池（Thread Pool）：客人走后，服务员不清退，留在“待命区”服务下一位（线程复用）。

    • 📦 连接池（Connection Pool）：应用程序提前创建一组连接放着，随用随取（避免频繁握手开销）。

    • ⚡ 效果：连接响应速度提升 30%+，抗并发能力更强！

4. 其他隐藏功能

  • 内存检查：像“餐前消毒”——检查连接是否携带恶意代码（如超大SQL攻击）。

  • 协议支持：适配不同“点餐方式”（通信协议：TCP/IP、Socket、命名管道）。

  • 字符集协商：确保顾客和服务员说同一种语言（如UTF8编码防乱码）。

连接层工作流程（举个🌰）

  1. 客人到店：
    → 应用程序（Java/Python）调用 mysql-connector 发起连接请求。

  2. 安检排队：
    → 连接层检查账号密码 → 通过后分配空闲线程（或创建新线程）。

  3. 分配座位：
    → 线程绑定连接 → 进入服务层执行SQL（如 SELECT * FROM users）。

  4. 客人离店：
    → 连接断开 → 线程回归线程池待命（非销毁）。

连接层的作用是处理客户端的连接，这个小节主要介绍MySQL Server如何管理连接，包括对可用连接接口的描述和服务器如何使用连接处理线程。

2.1. 网络端口

我们都知道MySQL是一个网络服务，我们可以通过ip地址和端口号来寻找到这个指定的MySQL服务。

程序在启动的时候可以向操作系统申请一个端口号，这样操作系统会将这个端口和这个进程进行关联。一般而言，一个进程使用一个端口就够了，但事实上一个进程可以使用多个进程，只需要我们告诉操作系统而且这些端口没有被占用即可。

对于MySQL而言，一台服务器能够侦听多个网络端口上的客户端连接，开放多个端口，只需在选项文件中指定多个端口即可，配置如下所示：

[mysqld] # mysqld节点
port=3306 #端口1
port=3307 #端口2

2.2. 连接管理线程

通过连接管理器线程处理端口上的客户端连接请求：

  • 在所有平台上，用一个管理器线程处理所有的TCP/IP连接请求。
  • 在Unix上，管理器线程还可以处理其他Unix socket 连接请求。
  • 在Windows上，使用一个管理器线程处理通过Shared-memory方式连接请求，使用另一个管理器线程处理Named-pipe方式连接请求。
  • 在所有平台上，可以额外启用一个端口用于接受针对管理的TCP/IP连接请求（类似于老板），管理端口的连接可以使用处理"普通"TCP/IP请求的管理器线程，也可以通过选项文件配置单独的线程（不做讨论）。

2.3.客户端连接线程管理

        连接管理器线程在接收到每个客户端连接后，把请求转发到真正的执行线程，每个请求都对应一个执行线程，该线程处理连接的身份验证和具体请求。

        执行线程使用线程池技术进行缓存，当一个请求需要处理时，先从线程池中查找是否有可用的线程，如果没有则新创建一个，当连接结束时，如果线程池没有满，则把当前线程放入线程池，主要的作用是提高线程的复用，减少创建线程造成的系统 开销从而提高效率。

可以通过以下几个系统变量和状态变量控制和监视服务器管理客户端连接的线程：

  •  系统变量thread_cache_size决定了线程池缓存的大小。默认情况下，服务器在启动时会自动调整这个值，但也可以通过选项文件明确指定大小，值为0时禁用缓存，此时为每个新连接创建执行一个线程，并在连接断开时释放；
  •  有些复杂的SQL语句在执行过程中可能会有深层递归从而消耗更多的内存，通过设置thread_stack=N 调整线程堆栈大小；
  •  要查看缓存中的线程数以及超过缓存数后新创建的线程数，通过状态变量 Threads_cached和Threads_created 查看；
 [mysqld] # mysqld节点thread_cache_size=16 #线程池大小thread_stack=1048576 #栈内存大小

 thread_cache_size 和 thread_stack 的大小需要根据机器的具体配置进行调整，具体优化
过程我们将在其他优化专题中介绍

2.4.连接量管理

  • 系统变量max_connections可以控制服务器允许同时连接的最大客户端数，当服务器达到max_connections指定的连接数时会拒绝所有新的连接请求，同时会增加状态变量Connection_errors_max_connections 的值；
  •  mysqld实际上允许 max_connections+1个客户端连接。额外的连接为拥有CONNECTION_ADMIN权限的帐户（管理员）使用，即使普通连接达到了 max_connections的数量，管理员也可以连接到服务器进行管理操作；
  •  在部署为主从复制的环境中，从节点的连接数也会计入max_connections中，如果连接达到上限主从复制将会失败；
  •  max_connections具体数据和服务器的硬件有关，比如可用的内存、每个连接消耗的内存，每个连接的工作负载、响应时间、可用文件描述符的数量等等，具体内容我们在其他优化专题中介绍。

三. 服务层

数据库服务层是整个数据库服务器的核心，主要包括了服务管理和公共组件、NoSQL和SQL接口、解析器、查询优化器和缓存等部分，下面我们分别介绍每个部分的作用：

3.1 服务管理和公共组件

MySQL提供了多种功能服务以满足不同使用场景下的需要，常用的服务如下：

  • Backup& Recovery：备份与恢复，在备份与恢复专题介绍；
  • Security：安全，在安全性与权限管理专题介绍；
  • Replication：主从复制，在主从复制专题介绍；
  • Cluster：MySQL集群，在MySQL集群专题介绍；
  • Partitioning：表分区，在分库分表与表分区专题介绍；
  • Instance Manager：实例管理，在系统数据库专题介绍；
  • Administrator：MySQL管理员，在安全性与权限管理介绍专题；
  • Migration Toolkit：迁移工具包，在安全性与权限管理专题介绍；

3.2 NoSQL接口与SQL接口

主要负责接收客户端发送的各种SQL语句和命令，并将SQL发送到其他部分，然后把接收到的结果返回给客户端。

NoSQL Interface（NoSQL接口）

功能：不用写SQL也能操作数据
类比：点奶茶时直接说“珍珠奶茶大杯少冰”（不用报菜单编号）
核心动作：

  • Create：存数据（下单）

  • Read：查数据（看订单）

  • Update：改数据（加珍珠）

  • Delete：删数据（退单）

SQL Interface（SQL接口）

功能：用SQL语句精细控制数据库
类比：写详细采购清单（商品名+数量+要求）
能干的事：

  • DML：增删改查数据（买/退/换货）

  • DDL：建表改表（设计货架布局）

  • Stored Proc：预设自动化流程（自动补货程序）

  • Views：创建虚拟数据看板（热销商品排行榜）

  • Triggers：设置数据变动触发器（库存<10自动报警）

3.3 Parser(语法分析器)

语法分析器的主要作用是将客户端发来的SQL语句中的关键字和自定义字段进行提取、解析，最终将SQL语句转换为一棵解析树，分析的过程中包含词法分析和语法分析；

  • 词法分析，主要是对关键字进行提取，比如 select/update/delete/create... ；
  • 语法分析，主要判断SQL语句是否满足语法规则，如果语法错误则异出异常，也就是我们常见的ERROR 1064 (42000): You have an error in your SQL syntax。
# 例如有如下SQL语句，对应的解析树大致如图所示
select sn,name from student where id = 1;

 

Parser（解析器）

功能：拆解SQL + 检查权限
类比：超市收银员扫码+安检
具体操作：

  • Query Translation：
    → 把 SELECT * FROM foods WHERE price<10 拆成：
      ① 拿 foods 表
      ② 筛选 price<10 的商品
      ③ 返回所有字段

  • Object Privilege：
    → 检查你是否有权限买烟（年龄够吗？）
    → 检查你是否能进VIP仓库（有没有权限？）

3.4 Optimizer(查询优化器)

功能：找出执行SQL的最快路径
类比：地图APP规划省时路线
决策逻辑：

  • Query Access Paths：
    → 用索引（走高速）
    → 全表扫描（堵车时绕小路）

  • Statistics：
    → 分析数据分布（早高峰哪条路车少？）
    → 例子：查价格<100的商品，如果90%商品都满足，直接扫货架比查价签更快！

通过语法校验的SQL语句将进入查询优化器处理阶段，查询优化器会将解析树转化为查询计划， 一般情况下，一条查询可以有很多种执行方案，查询优化器会根据执行计划匹配合适的索引，选择最佳的执行方案，最终把确定要执行的SQL交给执行器调用存储引擎API。

TIPS:
        优化后的SQL语句在条件查询时可能与程序员写的条件过滤顺序不同，但最终的返回结果一致，具体的优化过程我们在查询优化专题中介绍。

        查询优化器会智能重排 WHERE 条件的执行顺序，但保证结果不变。下面用具体例子说明：

📌 场景对比

假设有一个商品表 products，包含 100 万条数据：

CREATE TABLE products (id INT PRIMARY KEY,name VARCHAR(100),price DECIMAL(10,2),category VARCHAR(50),INDEX idx_price (price),          -- 价格索引INDEX idx_category (category)     -- 类别索引
);

❌ 程序员写的原始 SQL（按直觉顺序）：

SELECT * FROM products
WHERE category = '电子产品'   -- 条件A：筛选出5%的数据AND price < 1000;          -- 条件B：筛选出80%的数据

✅ 优化器优化后的执行计划（实际执行顺序）：

-- 优化器实际执行顺序：
SELECT * FROM products
WHERE price < 1000           -- 先执行条件B（更快！）AND category = '电子产品';  -- 后执行条件A

🧠 优化器为什么调换顺序？

条件

过滤比例

是否有索引

执行代价

category='电子产品'

5%

✅ 有索引

低（只需查5%数据）

price < 1000

80%

✅ 有索引

高（要查80%数据）

优化器的决策逻辑：

  1. 如果先执行 category='电子产品'（条件A）：
    → 用索引快速找出 5% 的数据（5万条）
    → 再在这5万条中筛选 price<1000（80%满足，剩4万条）

  2. 如果先执行 price<1000（条件B）：
    → 用索引扫描 80% 的数据（80万条）
    → 再在这80万条中筛选 category='电子产品'（只剩5%，仍是4万条）

结论：
→ 先执行过滤性强的条件（5%）效率更高！优化器会自动选择最优路径.

3.5 Caches & Buffers(缓存)

        MySQL的缓存主要的作用是为了提升查询的效率，当服务器接收到一个select查询语句时，会先进入缓存查询当前SQL语句在缓存中是否存在，缓存以key和value的形式存储，key是具体的SQL语句，value是结果的集合，如果命中缓存，直接返回结果，无法命中缓存，则进入分析器进行正常查询流程。

        这里需要说明的是，缓存数据对应的数据在被更新之后将会失效，尤其在写多读少的场景中，缓存会频繁失效与新增，命中率非常低，因此MySQL5.6之后服务层缓存功能默认关闭，而且在MySQL8.0中服务层缓存被官方删除，这里不做过多讨论。

3.6 SQL语句的执行流程

如下图所示

SQL执行全流程描述

  1. 客户端发起请求：应用程序（如Java/Python）通过连接驱动发送SQL语句（如 SELECT * FROM users）到MySQL服务器。

  2. 连接池接收：请求进入连接池，分配空闲线程处理（避免频繁创建线程）。

  3. SQL解析器解析：SQL解析器拆解语句→检查语法（如关键词拼写错误）。

  4. 预处理器校验：预处理器检查语义→确认表/字段是否存在→验证用户权限（如能否访问 users 表）。

  5. 优化器决策：SQL优化器选择最优执行路径（如用索引查 id 还是全表扫描）→生成执行计划。

  6. 执行器操作：执行器调用 Handler API，按计划操作存储引擎（如："从 users 表读第1~100行"）。

  7. 存储引擎执行：存储引擎（如InnoDB）访问磁盘数据→从文件读取记录→返回给执行器。

  8. 结果返回：执行器整理结果→经连接池原路返回→客户端驱动接收数据。

  9. 响应输出：应用程序获得查询结果（如用户列表）。

 

http://www.dtcms.com/a/268423.html

相关文章：

  • 【HarmonyOS】鸿蒙应用开发Text控件常见错误
  • AI+Web3：从自动化工具到自主经济体的范式革命
  • 爬虫-协议基础
  • 1865.找出和为指定值得下标对
  • Java笔记-下
  • MyBatis-Plus分页拦截器原理深度解析
  • new与malloc[c++面试系列]
  • GCC/G++编译器详解：从编译原理到动静态链接
  • 2025 JuniorCryptCTF re 部分wp
  • 【一起来学AI大模型】算法核心：数组/哈希表/树/排序/动态规划（LeetCode精练）
  • 【Docker基础】Docker数据卷管理：docker volume rm与prune命令对比
  • 计算机网络实验——配置ACL
  • vue3 当前页面方法暴露
  • 「Java题库」基础程序设计（理论+操作）
  • Excel 日期计算与最小日期选择(附示例下载)
  • DAY 49
  • monorepo + Turborepo --- 开发应用程序
  • Go语言实现双Token登录的思路与实现
  • 微服务基础：Spring Cloud Alibaba 组件有哪些？
  • 随机森林算法详解：Bagging思想的代表算法
  • 自存bro code java course 笔记(2025 及 2020)
  • 【Linux网络编程】Socket - UDP
  • CppCon 2018 学习:What do you mean “thread-safe“
  • Linux操作系统之文件（五）：文件系统（下）
  • 数据库|达梦DM数据库安装步骤
  • 谷歌浏览器安全输入控件-allWebSafeInput控件
  • 黑布淡入淡出效果
  • Vue2 day07
  • STM32两种不同的链接配置方式
  • Python 中 ffmpeg-python 库的详细使用