MySQL

一、第一性原理：MySQL 在解决什么问题

任何数据库系统，本质上都在同时解决四类相互冲突的问题：

  1. **高并发访问**：大量客户端同时读写
  2. **数据一致性**：事务正确性与隔离
  3. **崩溃恢复**：进程/机器故障后不丢数据、不乱数据
  4. **分布式复制**：跨节点的数据一致性与扩展性

MySQL 的所有设计，都可以回溯到这四个目标之间的权衡。

二、总体架构：职责分离而非一体化设计

2.1 逻辑架构的核心思想

MySQL 并不是一个“整体数据库”，而是一个分层、可插拔的系统：

这种分层的本质目的：

将“通用数据库能力”与“数据存储实现”解耦

2.2 核心组件职责模型

组件核心职责
连接管理并发控制、资源隔离
SQL 解析/优化语义正确性、执行效率
执行器调度存储引擎
存储引擎数据组织、事务、日志

三、执行路径：一次查询如何在系统中流动

3.1 从客户端到执行器

查询生命周期：

  1. 连接建立（线程/连接资源）
  2. SQL 解析（语法 → 语义）
  3. 查询优化（代价模型）
  4. 执行计划下发给存储引擎

3.2 结果集返回的工程本质

这解释了：

四、事务系统：一致性是如何被构造出来的

4.1 事务的三层实现模型

层次机制解决的问题
事务语义层ACID正确性定义
逻辑并发层MVCC读写并发
物理并发层锁写写冲突

五、日志体系：三种日志，三个时间维度

5.1 日志不是备份，而是状态机

MySQL 使用多日志，并非冗余，而是职责拆分。

5.2 三类日志的第一性原理

日志解决的问题时间维度
redo log崩溃一致性物理时间
undo log回滚 / MVCC逻辑时间
binlog跨节点复制分布式时间

5.3 两阶段提交的本质

两阶段提交不是为了复杂，而是为了消除日志系统之间的不一致状态。

六、锁体系：并发控制而非性能优化

6.1 锁存在的根本原因

当多个事务同时修改不可分割资源时，必须牺牲并发换取正确性。

6.2 InnoDB 锁的层次结构

6.3 为什么间隙锁只存在于 RR

因为 RR 试图在“不加读锁”的前提下避免幻读。

七、DDL 与元数据：结构变化也是事务

7.1 元数据锁（MDL）的设计动机

表结构本身就是共享资源。

7.2 DDL 算法演进路径

算法核心取舍
COPY简单但阻塞
INPLACE并发但复杂
INSTANT极快但受限

八、高可用：故障是常态而非异常

8.1 高可用的本质目标

8.2 可用性演进模型

  1. 单机恢复
  2. 主从复制
  3. 自动化切换

九、配置参数：参数不是知识，取舍才是

9.1 三类配置心法

9.2 典型权衡示例

十、总结：如何长期掌握 MySQL

关联内容（自动生成）