MySQL架构和历史

MySQL逻辑架构

1. 第一层处理网络连接等, 比如链接认证授权等

2. 第二层是 MySQL 的核心, 用来解析优化 SQL 语句, 设计缓存, 以及各种函数的实现, 包括存储过程, 触发器, 视图等

3. 第三层包括存储引擎, 负责具体数据的存取, 服务器通过 API 和存储引擎通信, 存储引擎只执行来自上层的请求

• 每个客户端连接都在服务器进程中有一个线程, 服务器负责缓存线程, 不需要手动管理

• 服务器处理连接流程

  1 2 3 4 5 6 7 8 9 10

  graph LR start[客户端连接] auth[检查用户名密码] access[检查是否有对应资源的处理权限] query[执行SQL 操作] start-->auth auth-->access access-->query

并发控制

MySQL 会在两个层面做并发控制: 服务器层和存储引擎层

• 读写锁

1. 读锁(共享锁)是共享的, 互相不阻塞

2. 写锁(排他锁)是排他的, 给定时间内, 只有一个用户能写入

表锁在服务器层实现, 行锁在存储引擎层实现

事务

• 数据库事务具有, 原子性, 一致性, 隔离性和持久性, 简称 ACID

• 使用事务会增加额外的开销

• 隔离级别

1. READ UNCOMMITTED 未提交读, 就是在A事务还没有提交的时候, B操作可以读取 A 修改的数据, 即脏读, 一般不使用这种隔离方式

2. READ COMMITTED 提交读, 事务在提交之前, 对其他的事务不可见, 即只对自己事务内部的数据有影响, 也叫不可重复读

3. REPEATEABLE READ 可重复读, A 事务本身对数据的修改对 A 事务后边的语句也不起作用, 所有的 SQL 操作的数据都来自数据库, 这是 MySQL 默认的事务隔离级别

4. SERIALIZABLE 可串行化, 这种会在事务操作的每一行记录上都加一个锁, 会严重降低性能, 但是数据一致性比较高

事务日志是顺序 I/O, 日志采用追加的方式

MySQL 的每个查询都被当成一个事务执行

Innodb 的 MVCC (多版本并发控制) 的实现方式 \

只工作在 REPEATEABLE 和 READ COMMITED 两种隔离级别下

为每一行记录增加两个字段, 一个保存行的创建时间, 另一个保存行的过期/删除时间, 具体存储的是一个版本号, select 的时候会首先读创建版本号小于或等于当前事务版本号, 并且删除版本号为空或者大于当前事务的版本号, inssert 更新创建版本号, delete 会更新删除版本号, update 更新创建版本号为当前系统版本号, 更新删除版本号为之前的创建版本号

存储引擎

• InnoDB

  • 支持行级锁

  • 支持事务

  • 全表使用 B+ tree 实现

  • 数据只存在叶子节点上

• MyISAM

  • 不支持行级锁, 只支持表锁

  • 数据文件和索引文件分开

  • 不支持事务

  • 可以通过压缩表技术提高性能

  • 索引使用 B+ tree 实现