MySQL 最重要、最与众不同的特性是它的存储引擎架构，这种架构的设计将查询处理及其他系统任务和数据的存储/提取相分离。 这样做带来的一个便利就是：我们可以根据不同的业务场景选择适合的数据存储方式。

MySQL 的逻辑架构

总体来说分为三层：

第一层服务

连接管理、授权认证、安全

这一层是很多基于网络的客户端、服务器都有的架构，当客户端（应用）连接到 MySQL 服务器时，服务器需要对其进行认证，比如常见的命令：
mysql -u root -p

客户端连接成功后，服务器会继续验证该客户端是否具有执行某个特定查询的权限。

第二层服务

大多数 MySQL 的核心服务功能都在这一层，包括：查询解析、分析、优化、缓存，所有的内置函数，所有的跨存储引擎的功能都在这一层实现。

解析器、优化器及查询缓存

MySQL 会解析查询，并创建内部数据，对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。用户可以和该过程进行交互，比如可以通过特殊的关键字提示优化器，影响它的决策过程；也可以请求优化器解释优化过程的各个因素，用户可以基于这些信息重构查询、修改配置等，从而更高效地使用 MySQL。

MySQL 支持不同的存储引擎，优化器本身并不关心用户具体选择哪一种存储引擎，但是存储引擎对于优化查询是有影响的。

对于 SELECT 语句，在解析查询之前，服务器会先检查查询缓存，命中缓存时就不必再执行查询解析、优化等过程，直接返回命中的结果集。

并发控制，读锁与写锁

只要有多个查询在同一时刻修改数据，都会产生并发控制的问题。在处理并发读或写时，可用通过实现一个由读锁和写锁组成的锁系统来解决问题。读锁是共享的，写锁是排他的，确保在给定的时间里，只有一个用户执行写入，并防止其他用户读取正在写入的同一资源。不过这会引出另外两个问题：脏读和幻读。

锁的粒度

很容易理解，缩小锁的范围可以提高并发。最理想的方式是，只对会修改的数据片进行精确地锁定。但另一方面，加锁会增加系统的开销。如果系统花费大量的时间来管理锁，而不是在存取数据，系统的性能会受到影响，因此需要一定的锁策略，即在锁的开销和数据的安全性之间寻求平衡。MySQL 的灵活体现在：各种存储引擎都可以实现自己的锁策略及锁粒度。

表锁

表锁是 MySQL 中最基本的锁策略，会锁定整张表，开销最小。MySQL 的服务器层只实现了表锁。

行级锁

只锁定一行，可以最大程度地支持并发处理，相应的开销也最大。行级锁只在存储引擎层实现。

第三层服务

存储引擎。