一、MySQL架构核心层连接层连接器、认证授权、连接池/线程管理服务层解析器、优化器、执行器决定 SQL 怎么执行存储引擎层InnoDB/MyISAM 等负责数据存取常用 InnoDB事务与并发机制事务、锁、MVCC、隔离级别主要由 InnoDB 实现日志系统redo log、undo log、binlog可靠性恢复复制复制与高可用链路binlog - relay log - 从库回放主从与容灾基础二、MySQL整体架构图1、整体架构图2、InnoDB核心引擎图三、MySQL sql执行流程1、查询的执行流程1客户端发起连接通过连接器完成鉴权、权限校验并分配连接线程。2发送 SQL 到 Server 层例如SELECT * FROM user WHERE id 10;3解析器Parser处理 SQL进行词法分析和语法分析生成语法树。如果 SQL 语法有问题通常在这一阶段报错。4优化器Optimizer生成执行计划决定索引选择、表连接顺序、是否需要回表、是否使用排序或临时表等。EXPLAIN 看到的就是优化器选择的执行计划。5执行器Executor按计划执行执行器基于执行计划调用存储引擎接口读取数据不直接操作磁盘文件。6InnoDB 读取数据先在 Buffer Pool 中查找目标数据页未命中时从磁盘加载数据页到内存若走二级索引可能需要回表到聚簇索引获取完整行数据7事务可见性判断MVCC普通 SELECT 属于快照读会基于 Read View 判断版本可见性。RC每条语句都会创建新的 Read ViewRR事务中第一次快照读创建 Read View后续复用8返回结果给客户端执行器将满足条件的数据按 MySQL 协议返回给客户端。补充1、MySQL 8.0 已移除查询缓存Query Cache。2、普通 SELECT 一般不加锁SELECT ... FOR UPDATE 属于当前读会加锁。2、更新的执行流程1客户端发起连接通过连接器完成鉴权、权限校验并分配连接线程。2发送 UPDATE SQL 到 Server 层例如UPDATE user SET name A WHERE id 10;3解析器Parser处理 SQL进行词法分析、语法分析生成语法树。语法错误通常在这里被发现。4优化器Optimizer生成执行计划决定使用哪个索引、扫描方式、是否回表等。如果 WHERE 条件没命中合适索引可能导致大量扫描和锁冲突。5执行器Executor调用 InnoDB执行器按执行计划调用存储引擎接口开始定位并更新目标行。6InnoDB 定位目标行并加锁当前读UPDATE 属于当前读会读取最新版本并对目标记录加锁通常是行锁必要时出现间隙 锁/next-key lock。7写 Undo Log修改前镜像在真正修改数据前先记录 undo 信息用于事务回滚MVCC 提供旧版本读取8修改 Buffer Pool 中的数据页在内存页中完成数据变更页面变为脏页dirty page。9写 Redo LogWAL记录物理层变更日志保证崩溃恢复能力。核心思想是先写日志再择机刷脏页到磁盘。10写 BinlogServer 层记录这次逻辑变更用于主从复制和归档恢复。11事务提交内部两阶段提交思想典型顺序可理解为redo log 进入 prepare 状态binlog 写入并刷盘redo log 标记 commit用于保证 redo 和 binlog 一致避免主从不一致。四、MySQL日志 RedoLog、UndoLog、 BinLog1、RedoLog(InnoDB执行引擎层)Redo Log 是 InnoDB 的物理重做日志核心作用是保证事务提交后的持久性和宕机恢复能力。InnoDB 采用 WAL 机制先写 Redo Log再异步刷数据页到磁盘所以提交成功不等于数据页已落盘。发生崩溃时数据库会通过重放 Redo Log 恢复已提交但尚未刷盘的数据。在开启 Binlog 时Redo Log 会和 Binlog 通过两阶段提交保证一致性避免主从数据不一致。常见配置上innodb_flush_log_at_trx_commit1 安全性最高性能会相对低一些。2、Undolog(InnoDB执行引擎层)Undo Log 是 InnoDB 的回滚日志核心作用是事务回滚和 MVCC 多版本并发控制。在执行更新前InnoDB 会先记录数据的旧版本到 Undo Log这样事务失败时可以回滚到修改前状态。普通 SELECT 的快照读本质上也是通过 Undo Log 找历史版本实现“读已提交”或“可重复读”的可见性规则。Undo Log 不是用来做崩溃重做的它主要负责“撤销”和“提供旧版本”与 Redo Log 配合完成事务一致性。3、BinLog(Server层)Binlog 是 MySQL Server 层的逻辑日志核心作用是主从复制和数据归档恢复。它记录的是事务对应的逻辑变更内容不属于某个具体存储引擎因此可用于跨引擎复制。事务提交时会先写 Binlog再与 InnoDB 的 Redo Log 通过两阶段提交保证一致性避免主从数据不一致。生产环境中sync_binlog1 安全性最高但性能开销更大取更大值可提升性能但会增加宕机丢日志风险。技术人也爱好文学请关注
MySQL系统架构
一、MySQL架构核心层连接层连接器、认证授权、连接池/线程管理服务层解析器、优化器、执行器决定 SQL 怎么执行存储引擎层InnoDB/MyISAM 等负责数据存取常用 InnoDB事务与并发机制事务、锁、MVCC、隔离级别主要由 InnoDB 实现日志系统redo log、undo log、binlog可靠性恢复复制复制与高可用链路binlog - relay log - 从库回放主从与容灾基础二、MySQL整体架构图1、整体架构图2、InnoDB核心引擎图三、MySQL sql执行流程1、查询的执行流程1客户端发起连接通过连接器完成鉴权、权限校验并分配连接线程。2发送 SQL 到 Server 层例如SELECT * FROM user WHERE id 10;3解析器Parser处理 SQL进行词法分析和语法分析生成语法树。如果 SQL 语法有问题通常在这一阶段报错。4优化器Optimizer生成执行计划决定索引选择、表连接顺序、是否需要回表、是否使用排序或临时表等。EXPLAIN 看到的就是优化器选择的执行计划。5执行器Executor按计划执行执行器基于执行计划调用存储引擎接口读取数据不直接操作磁盘文件。6InnoDB 读取数据先在 Buffer Pool 中查找目标数据页未命中时从磁盘加载数据页到内存若走二级索引可能需要回表到聚簇索引获取完整行数据7事务可见性判断MVCC普通 SELECT 属于快照读会基于 Read View 判断版本可见性。RC每条语句都会创建新的 Read ViewRR事务中第一次快照读创建 Read View后续复用8返回结果给客户端执行器将满足条件的数据按 MySQL 协议返回给客户端。补充1、MySQL 8.0 已移除查询缓存Query Cache。2、普通 SELECT 一般不加锁SELECT ... FOR UPDATE 属于当前读会加锁。2、更新的执行流程1客户端发起连接通过连接器完成鉴权、权限校验并分配连接线程。2发送 UPDATE SQL 到 Server 层例如UPDATE user SET name A WHERE id 10;3解析器Parser处理 SQL进行词法分析、语法分析生成语法树。语法错误通常在这里被发现。4优化器Optimizer生成执行计划决定使用哪个索引、扫描方式、是否回表等。如果 WHERE 条件没命中合适索引可能导致大量扫描和锁冲突。5执行器Executor调用 InnoDB执行器按执行计划调用存储引擎接口开始定位并更新目标行。6InnoDB 定位目标行并加锁当前读UPDATE 属于当前读会读取最新版本并对目标记录加锁通常是行锁必要时出现间隙 锁/next-key lock。7写 Undo Log修改前镜像在真正修改数据前先记录 undo 信息用于事务回滚MVCC 提供旧版本读取8修改 Buffer Pool 中的数据页在内存页中完成数据变更页面变为脏页dirty page。9写 Redo LogWAL记录物理层变更日志保证崩溃恢复能力。核心思想是先写日志再择机刷脏页到磁盘。10写 BinlogServer 层记录这次逻辑变更用于主从复制和归档恢复。11事务提交内部两阶段提交思想典型顺序可理解为redo log 进入 prepare 状态binlog 写入并刷盘redo log 标记 commit用于保证 redo 和 binlog 一致避免主从不一致。四、MySQL日志 RedoLog、UndoLog、 BinLog1、RedoLog(InnoDB执行引擎层)Redo Log 是 InnoDB 的物理重做日志核心作用是保证事务提交后的持久性和宕机恢复能力。InnoDB 采用 WAL 机制先写 Redo Log再异步刷数据页到磁盘所以提交成功不等于数据页已落盘。发生崩溃时数据库会通过重放 Redo Log 恢复已提交但尚未刷盘的数据。在开启 Binlog 时Redo Log 会和 Binlog 通过两阶段提交保证一致性避免主从数据不一致。常见配置上innodb_flush_log_at_trx_commit1 安全性最高性能会相对低一些。2、Undolog(InnoDB执行引擎层)Undo Log 是 InnoDB 的回滚日志核心作用是事务回滚和 MVCC 多版本并发控制。在执行更新前InnoDB 会先记录数据的旧版本到 Undo Log这样事务失败时可以回滚到修改前状态。普通 SELECT 的快照读本质上也是通过 Undo Log 找历史版本实现“读已提交”或“可重复读”的可见性规则。Undo Log 不是用来做崩溃重做的它主要负责“撤销”和“提供旧版本”与 Redo Log 配合完成事务一致性。3、BinLog(Server层)Binlog 是 MySQL Server 层的逻辑日志核心作用是主从复制和数据归档恢复。它记录的是事务对应的逻辑变更内容不属于某个具体存储引擎因此可用于跨引擎复制。事务提交时会先写 Binlog再与 InnoDB 的 Redo Log 通过两阶段提交保证一致性避免主从数据不一致。生产环境中sync_binlog1 安全性最高但性能开销更大取更大值可提升性能但会增加宕机丢日志风险。技术人也爱好文学请关注
