MySQL 的架构特点使其可以被应用在很多场景中。尽管它并不完美，但足够灵活，从小型的个人网站到大型的企业应用它都可以工作得很好。为了最大限度地使用 MySQL，你需要了解它的设计，以便能够用其所长，避其所短。
01
MySQL的逻辑架构是什么
如果能在脑海中构建出一幅 MySQL 各组件之间协同工作的架构图，那么这将有助于你深入理解 MySQL 服务器。
最上层的客户端所包含的服务并不是 MySQL 独有的，大多数基于网络的客户端 / 服务器工具或服务器都有类似的服务，包括连接处理、身份验证、确保安全性等。
第二层是比较有意思的部分。大多数 MySQL 的核心功能都在这一层，包括查询解析、 分析、优化、以及所有的内置函数（例如，日期、时间、数学和加密函数），所有跨存储引擎的功能也都在这一层实现：存储过程、触发器、视图等。
第三层是存储引擎层。存储引擎负责 MySQL 中数据的存储和提取。和 GNU/Linux 下的各种文件系统一样，每种存储引擎都有其优势和劣势。服务器通过存储引擎 API 进行通信。这些API屏蔽了不同存储引擎之间的差异，使得它们对上面的查询层基本上是透明的。存储引擎层还包含几十个底层函数，用于执行诸如“开始一个事务”或者“根据主键提取一行记录”等操作。但存储引擎不会去解析 SQL ，不同存储引擎之间也不会相互通信，而只是简单地响应服务器的请求。
02
MySQL的隔离级别
隔离性在实际操作中比看起来复杂得多。ANSI SQL 标准定义了 4 种隔离级别。如果你是数据库领域的新手，我们强烈建议你在阅读特定的 MySQL 实现之前先熟悉 ANSI SQL 的通用标准。这个通用标准的目标是定义在事务内外可见和不可见的更改的规则。较低的隔离级别通常允许更高的并发性，并且开销也更低。
下面简单地介绍一下这 4 种隔离级别。
READ UNCOMMITTED（未提交读）
在READ UNCOMMITTED 级别，在事务中可以查看其他事务中还没有提交的修改。这个隔离级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他级别好太多，却缺乏其他级别的很多好处，除非有非常必要的理由，在实际应用中一般很少使用。读取未提交的数据，也称为脏读（dirty read）。
READ COMMITTED（提交读）
大多数数据库系统的默认隔离级别是 READ COMMITTED（但 MySQL 不是）。READ COMMITTED 满足前面提到的隔离性的简单定义 ：一个事务可以看到其他事务在它开始之后提交的修改，但在该事务提交之前，其所做的任何修改对其他事务都是不可见的。这个级别仍然允许不可重复读（nonrepeatable read），这意味着同一事务中两次执行相同语句，可能会看到不同的数据结果。
REPEATABLE READ（可重复读）
REPEATABLE READ 解决了 READ COMMITTED 级别的不可重复读问题，保证了在同一个事务中多次读取相同行数据的结果是一样的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读（phantom read）的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行（phantom row）。InnoDB 和 XtraDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读的问题。本章稍后会对此做进一步讨论。
REPEATABLE READ 是 MySQL 默认的事务隔离级别。
SERIALIZABLE（可串行化）
SERIALIZABLE 是最高的隔离级别。该级别通过强制事务按序执行，使不同事务之间不可能产生冲突，从而解决了前面说的幻读问题。简单来说，SERIALIZABLE 会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中很少用到这个隔离级别，除非需要严格确保数据安全且可以接受并发性能下降的结果。
表 1-1 概述了这几种隔离级别之间的利与弊。
