最近要搞MySQL 相关的工作, 工欲善其事必先利其器, 简单了解了下MySQL 的架构
MySQL 架构
分了4层:
-
- Connection/thread handling. mysql 为每个连接创建了一个线程, 并且整个过程都在此线程内完成. 而线程会被缓存, 不会为每个连接创建一个新的. 这层还会把认证及权限的工作做了.
- Query cache/ Parser. select 指令到达后, 会先去cache 中, 看是否有命中记录, 有即直接返回结果. Parser 会解析并创建一用于描述指令的数据结构(parser tree).
- Optimizer. 这里会对parser tree 进行一系列的优化, 如 重写查询, 更改指令顺序等. 可以在查询中添加参数以修正优化的结果和行为. 并且可以输出记录以供指令的优化.
- Storage engines. 负责存储和读取所有mysql 的数据. 其中包括有性能优先, 空间优先等不同的引擎, 可以根据不同的应用场合选择.
数据一致性
MySQl 读写都有锁. MySQL 服务器及存储引擎都提供了多种锁的方案. 常用的lock 方式有2个:
-
- table locks. 最基本的锁方案. 写的时候会锁表, 其他读写操作都会阻塞, 直到操作结束. READ LOCAL 可以允许某些写操作. 而写操作有着更高的优先级, 即使处理队列中有读操作, 也会优先处理写操作.
- row locks. 是并发性最好的一种锁, 但也是消耗最多的. 只能由存储引擎支持, 一般认为只有InnoDB 和 Falcon 支持这种操作.
事务性:
事务性的衡量指标主要是 ACID (Atomicity, Consistency, Isolation, and Durability). MySQL 主要靠存储引擎做到事务性, 但服务器本身也要做许多的事情以达到事务的目的. 而事务性本身会占用更多的cpu, 更多的内存, 更多的磁盘空间. 所以是否需要事务性是选择存储引擎的一个重要的指标.
在一个事务中存在更新同一行数据的话, 可能出现死锁问题, 各个引擎实现有不一样. 某些存储引擎会超时, 某些会做检测, 如InnoDB. 而发生这种情况都需要rollback, 死锁很难避免.
事务性分4个等级: READ UNCOMMITTED, READ COMMITTED , REPEATABLE READ , SERIALIZABLE 具体意义参考手册
事务log. 基本上所有存储引擎都这么做: 先把数据写到内存中, 并记录log到磁盘上, 最终(可能在某个时刻) 更新到磁盘的数据库上. 这也意味着一次事务将至少写2次IO
MySQL 默认使用AUTOCOMMIT, 就是说每条指令都将默认在一个事务中进行, 除非你明确指定.
不要在一个事务中混合使用支持和不支持的存储引擎.
InnoDB 可以指定使用LOCK
-
- SELECT … LOCK IN SHARE MODE
- SELECT … FOR UPDATE
也可以使用服务器提供的:
-
- LOCK TABLES
- UNLOCK TABLES
但这两条指令很危险, 容易带来性能问题. 所以除非在事务中, 并且AUTOCOMMIT 不生效的情况下谨慎使用它们.
多版本并发控制(Multiversion Concurrency Control):
一些存储引擎如InnoDB, Falcon, and PBXT 支持这个技术. 可以不锁读取非在写的行, 所以意味着更高的并发性, 但同时带来更高的消耗(数据镜像及各种检查).
数据引擎:
MySQL 会为每个表 建立一个同名文件于文件系统中, 并以.frm 为后缀, 主要记录着表的元信息.