MySQL逻辑架构地图：连接层、服务层、引擎层与一条SQL的完整旅程

如果你去问一个写了三五年后端的人，MySQL 为什么快、为什么慢，他多半能讲出索引、事务隔离级别、redo log、binlog 这些关键词；但你再追一句：一条 UPDATE 语句从客户端发出去，到事务真正提交，中间到底经过了哪些组件、哪些日志先写、哪些后写，很多人就开始含糊了。我见过不止一个同学，慢查询调了半天，最后发现卡在连接层；也有团队排查主从延迟，把参数翻了个底朝天，其实根源是两阶段提交的顺序理解错了。这些问题的共同点，都是缺一张“MySQL 逻辑架构”的全局地图。

这篇文章想把这张地图补上。我会把 MySQL 的逻辑架构拆成四层讲清楚：连接层、服务层、存储引擎层、文件存储层，再从一条查询和一条更新的完整旅程出发，把解析、优化、执行、日志写入、两阶段提交这些概念安放到它们真正所属的位置。同时结合我实际排查中遇到的场景，告诉你如何用架构视角快速定位问题。适合刚入门的同学建立整体框架，也适合工作两三年的后端或 DBA 用来补齐知识盲区。读完你会发现，很多“玄学”问题，其实都是架构层的确定性事件。

1. 先拉通全局：MySQL 这个系统到底分了几层

1.1 四层模型：连接层、服务层、引擎层、文件层

MySQL 的逻辑架构最核心的一张图，可以归纳为四个层次。客户端和驱动在最外面，通过连接器进入系统；连接器负责身份认证、权限校验和连接管理，给每个会话分配一个线程。紧接着是服务层（Server Layer），这一层包含了 SQL 接口、解析器、优化器、执行器，还有早期的查询缓存（8.0 已彻底移除）。再往下是存储引擎层，InnoDB、MyISAM、Memory 等引擎都挂在这里，它们通过统一的 handler 接口对接服务层。最底下是文件存储层，也就是 OS 文件系统上的数据文件、日志文件、表结构定义文件。

我用一句话概括它们的分工：连接层管“你是谁、能不能进”，服务层管“这句话什么意思、怎么执行最优”，引擎层管“数据到底怎么存、怎么读、事务和锁怎么处理”，文件层管“最终落在磁盘哪里”。这里最容易被忽略的是服务层和引擎层的边界。很多人以为 MySQL 就是 InnoDB，其实 InnoDB 只是默认引擎，它既不负责解析 SQL，也不负责生成执行计划；SQL 的解析、优化、执行调度，全部发生在服务层。引擎层只按照 handler 接口暴露能力，执行器来调用它们。

当客户端发来一条 SELECT 语句，典型的路径是：连接器确认身份并查询权限，然后把语句交给服务层，服务层依次经过解析器生成语法树、预处理器检查表和列是否存在、优化器生成执行计划、执行器调用存储引擎接口逐行取数，最后把结果返回给客户端。这条路径看似简单，但每一步都可能成为瓶颈，也每一步都有对应的排查工具。

1.2 分层设计解决了什么，又牺牲了什么

分层架构最大的好处是解耦。早期的 MySQL 支持多种存储引擎，就是因为服务层统一了 SQL 标准接口，任何引擎只要实现 handler 接口就能被服务层驱动。你要加一个全新引擎，写清楚打开表、读行、写行、加锁这些原语，SQL 解析和优化逻辑几乎不用动。这也是 MySQL 能长期保持生态活力的原因之一——引擎是插件化的，服务层是稳定的。

但分层不是没有代价。服务层和引擎层之间是跨模块通信，每次取数都要通过接口调用，数据行还得在引擎缓冲区和服务层内存之间来回复制。尤其在做全表扫描或大批量返回时，这种“搬运成本”会非常明显。另外，服务层有服务层的缓存和状态，引擎层有引擎层的缓存和状态，两层都要维护一致性，稍不注意就会踩坑。最典型的就是查询缓存：它曾经挂在服务层，却无法感知引擎层数据页的变化，每次表有更新就要失效大量缓存结果，反而在高并发写入场景下成为全局锁级别的瓶颈。官方最终在 8.0 直接把这一层摘掉了。这是分层设计里“缓存一致性代价”的活教材。

理解这些，你再看后面的内容就会轻松很多：服务层负责“解释和执行”，引擎层负责“存储和事务”，日志也不是全部在一个地方——binlog 在服务层，redo log 和 undo log 在引擎层。这种“日志分居”的设定，直接引出了更新语句里最著名的两阶段提交。

2. 服务层内部流水线：从连接器到执行器

2.1 连接管理：你的 SQL 从“进门”开始

逻辑架构图最左边是连接器。不管你用命令行、JDBC、Python 驱动还是连接池，第一站都是它。连接层要做的事包括：校验用户名密码、检查 host 是否允许访问、加载权限表、为会话分配线程和内存。MySQL 8.0 里默认认证插件是 caching_sha2_password，很多老客户端连不上去，就是这里的问题。

连接管理的另一个重点是线程模型。MySQL 为每个连接分配一个专用线程，这个线程的生命周期与连接绑定。连接多了，线程切换和内存占用就会上来。每个连接不是“零成本”——它有 net_buffer、线程栈等固定开销，所以 max_connections 不是越大越好。我曾经遇到一个业务库，连接池配了 800 个连接，max_connections 才 100，高峰期直接把服务压到“Too many connections”，新请求全部失败。调大参数只能临时缓解，真正的原因是有大量连接处于 Sleep 状态占着线程不释放。排查时看 show processlist，看到一堆 Time 很长、Command 为 Sleep 的会话，基本就能断定连接层出了问题。

连接层的调优方向很明确：控制连接数、缩短空闲会话生命周期、开启 thread cache。max_connections 要结合机器内存和 buffer pool 大小评估，thread_cache_size 则用来缓存空闲线程，减少频繁创建销毁线程的开销。很多资深 DBA 会把 wait_timeout 和 interactive_timeout 调到合适的值（比如 60 到 300 秒），让僵死连接尽快释放。

2.2 解析器与预处理器：SQL 是如何变成机器能懂的结构

连接建立后，SQL 文本正式进入服务层的解析阶段。解析器做的事情本质上是编译原理里的两步：词法分析和语法分析。

词法分析把 SQL 字符串拆成一个个 token。比如SELECT name FROM user WHERE id = 1，会被拆成 SELECT（关键字）、name（标识符）、FROM（关键字）、user（表名）等。语法分析则根据 MySQL 的语法规则，把这些 token 组合成一棵语法树（parse tree）。如果你写错了语法，比如少了 WHERE 关键字或者括号不匹配，解析器会直接报 1064 语法错误。这个错误发生在分析阶段，跟表是否存在、索引是否存在完全没有关系。

语法树生成之后，还要经过预处理阶段。预处理器会去查数据字典，确认表名、列名是否存在，把SELECT *展开成具体的列列表，解析视图的定义，并且做一次粗糙的权限检查。一个很常见的现象是，你执行SELECT * FROM no_such_table，报错“Table doesn't exist”，这个报错其实不是执行器报的，而是预处理器报的。所以排查这类错误时，不要往引擎层想，问题定位在服务层的解析/预处理阶段就对了。

有一点值得注意：解析和预处理本身也是消耗 CPU 的。一条 SQL 就算执行再快，如果被循环执行一万次，每次都要重新解析、重新生成语法树、重新优化，累计开销非常可观。这也是 ORM 框架底层普遍要做 prepared statement 缓存的原因——预编译的 SQL 可以跳过重复的词法和语法分析，省掉一大部分解析成本。

2.3 优化器：整个系统里最“自作主张”的组件

语法树和预处理通过以后，SQL 进入优化器。MySQL 的优化器是基于成本模型的（Cost-Based Optimizer，CBO），它会枚举可能的执行计划，估算每种计划的代价，选择它认为代价最小的那一个。

优化器要决定的事情很多：表连接顺序（join order）、使用哪个索引、采用哪种连接算法（Index Nested-Loop Join、Block Nested-Loop Join，8.0 里还有 Hash Join）、是否需要临时表排序、子查询如何改写等等。它的代价估算依赖表的统计信息，比如行数、索引基数（cardinality）、索引选择性。如果统计信息过期，优化器就可能做出错误决策。

我印象很深的一次排查：某张表原本走idx_status索引很快，某天突然变成全表扫描。EXPLAIN 一看 type 从 ref 变成了 ALL，key 变成 NULL。当时第一反应是索引坏了，但索引好好的。后来查优化器日志才明白，是因为表数据量翻了十几倍，而统计信息没有及时更新，优化器以为走idx_status要扫 10 万行，实际扫描可能只要几百行。执行ANALYZE TABLE重新收集统计信息后，执行计划恢复正常。这类问题完全不用改 SQL、不用加索引，根子在优化器依赖的统计信息上。

查看优化器决策，常用的手段是 EXPLAIN，它能告诉你最终选出来的执行计划长什么样。但 EXPLAIN 只展示结果，不展示“为什么”。想深挖决策过程，可以打开 OPTIMIZER_TRACE，它会记录优化器枚举计划、计算成本、最终选型的完整过程。排查选错索引的疑难杂症时，这两个工具一个看结果、一个看过程，配合着用非常管用。

2.4 执行器：打通服务层与引擎层的最后一环

优化器生成执行计划后，执行器正式开工。执行器本身不直接读磁盘，它把执行计划拆成一系列操作，逐条调用存储引擎的 handler 接口。比如要扫描全表，执行器会循环调用rnd_next或类似接口让引擎返回下一行；要走索引，就调用index_read接口，在索引定位后逐行读取。

执行器还负责把引擎返回的行做进一步处理。Using where代表引擎返回的行还需要在服务层做条件过滤；Using index代表所需列直接从索引中取得，不需要回表；而Using index condition（ICP，索引条件下推）则是把部分 WHERE 条件下推到引擎层过滤，减少返回给服务层的行数。这些信息都能从 EXPLAIN 的 Extra 列里看到，它们是服务层与引擎层协作方式的直观体现。

还有一个权限细节：连接建立时做了一次用户级认证，但每条 SQL 执行前，执行器还会基于当前用户权限做表和列级别的校验。比如用户只有某表的 SELECT 权限，执行 UPDATE 时，错误会在执行器阶段被拦下来。这也是为什么权限变更后新连接要重新认证或刷新权限缓存才能生效的原因。执行器阶段如果卡住，通常表现为 processlist 里的 State 是 “Sending data” 或 “executing”，这时候要把注意力放到引擎层的扫描、回表、锁等待上。

3. 跟着一条 SQL 走一遍：查询和更新的路径哪里不一样

3.1 查询 SQL 的完整流水账

把上面的组件串起来，一条查询 SQL 的完整路径是：连接器认证 -> 查询缓存检查（8.0 之前）-> 解析器解析 -> 预处理器检查 -> 优化器生成计划 -> 执行器调引擎执行 -> 返回结果。

如果你用的是 MySQL 8.0，查询缓存这一步可以忽略，5.7 里也默认不开启。MySQL 官方文档很早就在说查询缓存鸡肋，原因我在前面提过：它挂在服务层，却要感知引擎层的数据变化，乐观锁式的缓存失效在高并发写入下会变成严重瓶颈。所以现在讨论逻辑架构，最好把查询缓存当成历史遗留来看。

执行器拿到计划后，对普通查询通常会走两种路径之一：如果条件能用索引，引擎从 B+ 树索引中定位并读取；如果不能，引擎做全表扫描。InnoDB 的最小 IO 单位是页（默认 16KB），执行器要的行可能散落在不同页里，所以一次“SELECT 很多行”可能触发大量磁盘 IO。这也是为什么大范围扫描很慢，而走索引的精准定位很快。返回结果时，MySQL 不是等所有行都查完才一次性发送，而是边查边通过客户端协议缓冲分批发送。所以 processlist 里看到 “Sending data”，可能是在读取数据，也可能是在把数据写回客户端，排查时要结合时间戳判断。

3.2 更新 SQL 为什么绕不开 redo log 和 binlog

查询只读数据，更新则要先定位旧数据，再修改，再保证故障后不丢。

更新路径的第一个原则是 WAL（Write-Ahead Logging）：先写日志，再写数据页。InnoDB 拿到一条 UPDATE，会先在 Buffer Pool 中定位目标页；页不在内存就先从磁盘加载；然后写 undo log 记录旧值（用于回滚和 MVCC），修改内存中的页并标记为脏页；事务提交时，把本次修改以 redo log 形式顺序写入磁盘。脏页不用立刻刷盘，由后台线程择机刷，这就是为什么你更新一条 10KB 记录，磁盘上可能先只写了几百字节的 redo log。

redo log 是 InnoDB 引擎层的日志，它用来恢复物理页的变更；而 binlog 是服务层的日志，记录的是逻辑变更（语句或行事件），用于主从复制和数据恢复。这两个日志属于不同层，却要描述同一笔变更，如果没有协调机制，就会出现“引擎层提交了，服务层 binlog 没写”或者反过来，导致主从数据不一致。为了解决这个问题，MySQL 在更新提交时引入了两阶段提交（Two-Phase Commit）。

3.3 两阶段提交：一次断电事故的启发

两阶段提交的标准动作，是三次状态切换：

1. InnoDB 把该事务的 redo log 写入磁盘，状态置为 prepare；
2. 服务层将对应变更写入 binlog，并刷盘（取决于 sync_binlog 参数）；
3. InnoDB 把 redo log 状态改为 commit，事务正式提交。

为什么一定要这样？要害在崩溃恢复。假设刚写完 redo prepare 还没写 binlog 时断电，恢复时发现 binlog 里没有这个事务，系统判定这个事务可以回滚，数据页的修改会被回收。如果 redo prepare 和 binlog 都写完了，只是 commit 没来得及做，恢复时根据 binlog 完整存在，事务会被补提交。这就保证：binlog 里出现的事务，引擎层一定也有；binlog 没写的事务，引擎层一定不认。

我遇到过一起主库断电事故。重启后，一个已经提交给客户端的订单更新操作一开始看似丢失了，后来数据库恢复完，数据又出现了。客户端很困惑。其实就是两阶段提交里 commit 状态没来得及标记，但 binlog 已经完整写入，恢复线程根据 binlog 补提交了这条事务。理解了这个机制，你再去看binlog和redo log的顺序、sync_binlog和innodb_flush_log_at_trx_commit的参数组合，思路会清晰很多。这两个参数分别控制 binlog 和 redo log 的刷盘频率，它们直接决定“最多丢多少事务”，是数据安全与性能之间的天平。

3.4 undo log 在更新路径中还有一份

很多人只盯着 redo log 和 binlog，却忽略 undo log 也在更新路径中。undo log 是 InnoDB 引擎层的回滚日志，它记录的是“修改前的旧值”。事务回滚时，根据 undo log 把数据恢复原样；同时它也是 MVCC 多版本链的基础，读操作通过 undo 链找到对应版本的数据快照。

undo log 会在事务提交后由 purge 线程清理，但如果有长事务或大事务一直不提交，undo 链会被拉得很长，导致三个连锁问题：回滚时间变长、查询需要遍历的版本变多、undo 表空间膨胀。所以从架构视角看，更新 SQL 的路径上其实有三个日志：server 层写 binlog，引擎层写 redo log 和 undo log。日志分散在不同层，相互配合又各司其职，这也是 MySQL 事务能力和复制能力的基础。

4. 引擎层没那么简单：InnoDB 到底干了多少活

4.1 可插拔引擎机制的前因后果

存储引擎层是 MySQL 区别于很多数据库的独特设计。服务层只定义标准接口，具体实现交给引擎。你可以用SHOW ENGINES查看当前实例支持的引擎列表。早期 MyISAM 是默认引擎，但它不支持事务、不支持行锁，崩溃恢复能力弱；后来 InnoDB 因为支持事务、行锁、外键和崩溃恢复，成为默认引擎。可以说，MySQL 从“快速读写的文件系统”进化为“可靠的数据库”，InnoDB 功不可没。

从架构角度理解可插拔引擎，核心就是 handler 接口。它定义了打开表、读下一行、按索引定位、插入、更新、删除、加锁等操作原语。执行器不需要知道引擎内部怎么组织页、怎么管理锁，只需要调用这些原语。这也意味着，某些能力是引擎差异导致的：比如SELECT ... FOR UPDATE在 InnoDB 里是行锁，在 MyISAM 里其实是表锁，行为完全不同。

4.2 Buffer Pool：InnoDB 性能的核心

引擎层里，对性能影响最大的组件是 Buffer Pool。它是 InnoDB 在内存中的页缓存，数据页、索引页、undo 页的读写都先经过它。Buffer Pool 越大，能缓存的页越多，磁盘 IO 越少，性能通常越好。常见的经验值是物理内存的 50% 到 70%，但这不是绝对标准，还要考虑操作系统缓存、连接线程内存、排序缓冲等其他开销。

Buffer Pool 的淘汰策略不是简单 LRU，而是优化过的 LRU 变体，分 young 区和 old 区，避免一次全表扫描把高频热数据全部挤出缓存。刷脏页也不是一次全刷，由后台 page cleaner 线程控制频率，受innodb_io_capacity等参数约束。排查数据库卡顿的时候，如果看到磁盘写很高、Buffer Pool 命中率很低，方向往往就在引擎层缓存配置和刷盘策略上。

4.3 引擎层与 Server 层的边界：谁管锁、谁管日志

理解逻辑架构最容易犯的错，是分不清“哪些事归服务层、哪些事归引擎层”。我列几个最常见的划分：

• 行锁、间隙锁、死锁检测：InnoDB 引擎层职责；
• 表锁、元数据锁（MDL）、全局读锁：服务层职责；
• redo log、undo log：InnoDB 引擎层职责；
• binlog：服务层职责；
• 事务的原子性、持久性、隔离性具体实现：InnoDB 引擎层职责，服务层没有事务概念。

典型例子：一张表被ALTER TABLE阻塞，processlist 显示 “Waiting for table metadata lock”，这是服务层的 MDL 锁在等待。原因是前面有会话持有这张表的 MDL 读锁还没释放，DDL 需要 MDL 写锁。继续追一下，会发现持有锁的会话可能只是执行了一条普通的 SELECT 但所在事务迟迟没提交。这种问题不能用 InnoDB 的行锁知识解释，因为它发生在服务层。

4.4 其他引擎的逻辑差异

除了 InnoDB，还有几个引擎值得了解。

MyISAM 使用表级锁，不支持事务，崩溃恢复要么扫表修复要么丢失部分更新。但它有压缩表功能，适合某些只读归档场景，查询速度快且占用空间小。Memory 引擎把数据全部放内存，读写极快，但服务重启数据就没了，适合临时表、小字典表或中间结果。MySQL 在生成内部临时表时，优先用 Memory 引擎，如果临时表太大再转成磁盘临时表，这是服务层和引擎层交互时一个容易被忽视的细节。

这些引擎的差异提醒我们：当你说“MySQL 慢”的时候，先问一句是哪个引擎慢、慢在哪个层。同一个 SQL 在不同引擎上执行路径不同，排查方向也不同。好在绝大多数现代业务都用 InnoDB，后面的调优也以它为主。

5. 用逻辑架构做排查与调优：几个实战场景

5.1 连接数打满：先从连接层看起

数据库报 “Too many connections”，第一反应往往是调大max_connections。但我的建议是，先别急着调，先确认连接是不是真的“都在干活”。执行SHOW PROCESSLIST，如果看到大量 Command 为 Sleep、Time 几百秒的会话，说明它们是空闲连接占了连接数配额。

这种情况的根因通常在前端连接池配置：连接池最大连接数设置得过大，或者空闲回收时间太长。后端数据库这边能做的，是调低wait_timeout让空闲连接尽早被断开，开启thread_cache_size减少线程重建成本，再结合机器的内存上限重新评估max_connections。如果不解决源头，单纯调大连接数，只会把“Too many connections”变成“系统内存不足”。

5.2 一条慢 SQL，如何通过状态字定位组件

慢查询定位，我习惯先看SHOW PROCESSLIST的 State 字段，再决定要看哪一层的证据：

• Waiting for table metadata lock：卡在服务层 MDL 锁，多半是长事务或 DDL 等待；
• Sending data：执行器正在引擎层取数或返回数据，重点看扫描行数、回表次数、网络传输；
• updating stats：优化器正在更新统计信息，可能触发了统计重算导致整体变慢；
• Waiting for handler commit：执行器提交阶段等待引擎层完成日志写入，跟 redo log 刷盘策略有关。

举个例子，我曾经帮一位同事看一条查询，EXPLAIN 显示走了idx_order_no索引，type 是 ref，看起来没问题。但慢查询日志里 Rows_examined 高达几十万。后来发现是这条 SQL 返回了该订单下所有子记录，执行器在服务层对几万行做了逐行处理和回表，虽然索引定位很快，但回表行数太多，实际慢在了执行器与引擎层的协作上。这类问题，只看 EXPLAIN 的 key 列很容易被误导，结合 State 状态和 Rows_examined 才能还原全貌。

5.3 从架构位置理解几个常用参数

调优参数如果不知道它作用在哪一层，就很容易乱调。我把常用的参数按逻辑架构分层整理成一张对应表：

这张表最大的价值，是让你调参时心里有数。改innodb_flush_log_at_trx_commit影响的是引擎层持久性保证，改sync_binlog影响的是服务层复制日志的可靠性，两者要联动考虑。生产环境为了不丢数据，通常两个都设为 1；如果追求吞吐可以退到 0 或 2，但要接受潜在的数据丢失窗口。

5.4 调优顺序：先定位到层，再动手

以我自己的实践看，数据库调优最大的误区是“上来就改参数”。正确的顺序应该是：先定位问题发生在哪一层，再针对那一层采取措施。

步骤大致是这样：第一步，看SHOW PROCESSLIST，确认当前会话状态和卡点；第二步，看EXPLAIN，判断执行计划是否合理；第三步，如果计划不合理，再查统计信息、看OPTIMIZER_TRACE，判断是优化器估错了还是索引设计有问题；第四步，如果计划和执行都正常，再考虑引擎层参数，比如 Buffer Pool 大小、刷盘策略、IO 能力。大多数慢查询问题出在 SQL 写法和索引设计上，优化器只是背锅的那个。我在一个库里见过几十条慢 SQL，全是同一个类型：对一张大表ORDER BY不带过滤条件的全量排序，优化器被迫用 filesort 加临时表。这种问题改参数没用，改 SQL 或加覆盖索引才能真正解决。

6. 逻辑架构常见的三个理解误区

6.1 explain 的 rows 不是真实扫描行数

EXPLAIN 里的rows列经常被误解为实际扫描行数。它其实是优化器基于统计信息估算的值，代表它“预计要扫描多少行”。统计信息过期或者数据分布变化的时候，这个数字可能与实际执行相差一两个数量级。真实的扫描次数要看慢查询日志里的Rows_examined，或者用 performance_schema 事件表去量化。

这个误区的代价，是会让你错误地判断优化器的选择。比如 EXPLAIN 显示 rows=1000，实际执行扫描了 100 万行，你可能会误以为走了索引所以没问题。排查时把 EXPLAIN 和真实执行统计对齐，才能发现执行计划与实际执行之间的鸿沟。

6.2 锁并不都在引擎层

很多人一谈锁就只想到 InnoDB 的行锁，但逻辑架构里，锁有明确的分层归属。InnoDB 的行锁、间隙锁、插入意向锁都在引擎层，服务层则管理元数据锁（MDL）和表锁。

最常见的实战就是 MDL 锁等待。一个长时间未提交的事务持有某表的 MDL 读锁，后续对该表的 DDL 就会卡在 “Waiting for table metadata lock”。这类问题用SHOW ENGINE INNODB STATUS看不到行锁冲突，必须查 performance_schema 的 metadata_locks 表才能定位持有者。如果不理解锁分层，遇到这种问题很容易在错误的方向上浪费时间。

6.3 server 层和引擎层之间搬运数据的代价

最后一个误区是低估服务层与引擎层之间的数据传输成本。执行器通过 handler 接口逐行取数，每取一行都要把行数据从引擎层复制到服务层。SELECT 一个大字段、宽表或者返回几千列，都会放大这种复制成本；更可怕的是在循环里逐条执行 SQL，每次循环都把解析、优化、执行、返回整条流水线重新走一遍，性能会呈指数级下降。

我曾经帮一个团队优化批量更新，有人写了一个循环，每次循环执行一条 UPDATE，一万条数据跑了十几分钟。改成一条 UPDATE 用 CASE WHEN 或批量拼接后，几秒钟就完成了。这不是索引问题，纯粹是 SQL 没考虑逻辑架构的路径开销。每次 SQL 都要穿越连接层、服务层、引擎层，循环次数越多，穿越次数越多，累积成本越不可忽视。

回到我最初的问题：一条 UPDATE 在 MySQL 里到底经过了什么？现在你应该有了完整的画面——从连接器进入，解析器看懂语义，优化器决定路径，执行器调引擎，引擎写 undo log、改内存页、刷 redo log，服务层协调 binlog 完成两阶段提交，最终落盘。我自己的工作习惯是，遇到任何数据库问题，第一反应不是翻参数文档，而是在心里把问题放到四个层级里定位：连接层？服务层？引擎层？文件层？这一步定位准确了，解决方案通常会很清晰。想真正掌握 MySQL，逻辑架构永远是绕不开的第一块基石。