MySQL 逻辑架构

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

MySQL 的逻辑架构

总体来说分为三层:

第一层服务

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

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

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

第二层服务

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

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

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

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

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

并发控制,读锁与写锁

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

锁的粒度

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

表锁

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

行级锁

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

第三层服务

存储引擎。