MySQL最重要、最与众不同的特性是它的存储引擎架构,这种架构将查询处理与数据的存储/提取相分离,使得可以在使用时根据不同的需求来选择数据存储的方式。
如果能在头脑中构建出一幅MySQL各组件之间如何协同工作的架构图,就会有助于深入理解MySQL服务器。
mysql 数据库的逻辑架构如下图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Jx9utej6-1603348859176)(/Users/marron27/Documents/lizhengi/MySQL/高性能MySQL/T.Mysql逻辑图.png)]
从上图可以看出My SQL逻辑结构大致可以分为三层:
第一层结构主要处理客户端与mysql服务端的连接、授权认证、安全等;
第二层是Mysql服务端的核心,功能包括查询解析、分析、优化、缓存等,所有跨存储引擎的功能都在这一层实现:存储过程、触发器、视图等都在这一层实现;
第三层的存储引擎主要负责数据存储和提取,服务器通过API与存储引擎进行通信,存储引擎API包含几十个底层函数,用于执行诸如“开始一个事务”或者“根据 主键提取一行记录”等操作。但存储引擎不会去解析sql,不同存储引擎之间不会通讯,只会简单地响应上层服务器的请求
每个客户端连接成功,都会在服务器进程中拥有一个线程,服务器会缓存线程,该线程只能轮流在某个CPU中运行,所以不需要创建和销毁线程。
当客户端(应用)连接到MySQL服务器时,服务器需要对其进行认证。认证基于用户名、原始主机信息和密码等信息。
一旦客户端连接成功,服务器会继续验证该客户端是否具有执行某个特定查询的权限
MySQL会解析査询,并创建内部数据结构(解析树),然后对其进行各种优化,包括重 写查询、决定表的读取顺序,以及选择合适的索引等。
对于SELECT查询语句,解析查询之前会先查询缓存,如果缓存能找到是不会去解析的,如果缓存查找不到,就会重现解析查询,创建解析树,然后对其进行查询优化、决定表的读取顺序、选择合适的索引等
无论何时,只要有多个査询需要在同一时刻修改数据,都会产生并发控制的问题。
并发即指在同一时刻,多个操作并行执行。MySQL对并发的处理主要应用了两种机制——是"锁"和"多版本控制"。
在处理并发读或者写时,可以 通过实现一个由两种类型的锁组成的锁系统来解决问题:
所谓的锁策略,就是在锁的开销和数据的安全性之间寻求平衡,这种平衡当然也会影响到性能。
MySQL提供两个级别的并发控制:服务器级(the server level)和存储引擎级(the storage engine level)。加锁是实现并发控制的基本方法,MySQL中锁的粒度:
另外,值得一提的是,MySQL的一些存储引擎(如InnoDB、BDB)除了使用封锁机制外,还同时结合MVCC机制,即多版本并发控制(Multi-Version Concurrent Control),来实现事务的并发控制,从而使得只读事务不用等待锁,提高了事务的并发性。
MVCC的实现:通过保存数据资源在不同时间点的快照实现的。根据事务开始的时间不同,每个事务看到的数据快照版本是不一样的。
InnoDB中的MVCC实现:通过在每行记录后面保存两个隐藏的列来实现,一个保存了行的创建时间,一个保存了行的过期时间。
MVCC只在 REPEATABLE READ 和 READ COMMITTED 两个隔离级别下工作。
数据库的事务处理的原则是保证ACID的正确性。
事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性:
由于事务的并发执行,带来以下一些著名的问题:
READ UNCOMMITTED :事务可以看到其他事务没有被提交的数据(脏数据)。 READ COMMITTED :事务可以看到其他事务已经提交的数据。 REPEATABLE READ :保证事务中多次查询的结果相同(Innodb默认级别),会出现幻读。 SERIALIZABLE :所有事务顺序执行,对所有read操作加锁。保证一致性。
MySQL拥有分层的架构。上层是服务器层的服务和査询执行引擎,下层则是存储引擎。 虽然有很多不同作用的插件API,但存储引擎API还是最重要的。如果能理解MySQL 在存储引擎和服务层之间处理查询时如何通过API来回交互,就能抓住MySQL的核心 基础架构的精髓。
参考:
《高性能 MySQL 第三版》