浅谈mysql体系结构

一、mysql体系结构图简单介绍

以mysql为例，mysql体系结构如下图所示：

从上图可以看出，mysql只要分以下几个组件

1、连接池组件Connectors:值不同语言与sql的交互；
2、ManagementServices&Utilities:系统管理和控制工具；
3、Connection Pool: 连接池，管理缓冲用户连接，线程处理等需要缓存的需求；
4、SQL接口，接受用户的SQL命令，并且返回用户需要查询的结果。比如select from就是调用SQL Interface；
5、Parser: 解析器，主要功能：
　　a . 将SQL语句分解成数据结构，并将这个结构传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的。
　　b. 如果在分解构成中遇到错误，那么就说明这个sql语句是不合理的
6、 Optimizer: 查询优化器。
　　SQL语句在查询之前会使用查询优化器对查询进行优化。他使用的是“选取-投影-联接”策略进行查询。
　　用一个例子就可以理解： select customerid,name from customer where customerid = 1;
　　这个select 查询先根据where 语句进行选取，而不是先将表全部查询出来以后再进行customerid过滤；
　　这个select查询先根据customerid和name进行属性投影，而不是将属性全部取出以后再进行过滤；
7、Cache和Buffer： 查询缓存。如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据；
8、Engine ：存储引擎。
存储引擎是MySQL中具体的与文件打交道的子系统。也是MySQL最具有特色的一个地方。
　　MySQL的存储引擎是插件式的。它根据MySQL AB公司提供的文件访问层的一个抽象接口来定制一种文件访问机制(这种访问机制就叫存储引擎)。
　　现在有很多种存储引擎，各个存储引擎的优势各不一样，最常用的MyISAM,InnoDB,BDB。
　　默认下MySQL是使用MyISAM引擎，它查询速度快，有较好的索引优化和数据压缩技术。但是它不支持事务。
　　InnoDB支持事务，并且提供行级的锁定，应用也相当广泛。
　　MySQL也支持自己定制存储引擎，甚至一个库中不同的表使用不同的存储引擎，这些都是允许的
9、物理文件：包含日志文件、索引文件等

二、mysql存储引擎的简单介绍

首先看一下各个搜索引擎的特性

锁机制：
表级：直接锁定整张表，在你锁定期间，其它进程无法对该表进行写操作。如果你是写锁，则其它进程则读也不允许
行级：仅对指定的记录进行加锁，这样其它进程还是可以对同一个表中的其它记录进行操作。
页级：表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录

上述三种锁的特性可大致归纳如下：
1） 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
2） 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
3） 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
三种锁各有各的特点，若仅从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如WEB应用；行级锁更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统。

常用搜索引擎使用特点及使用场景：
MyISAM
特性
不支持事务：MyISAM存储引擎不支持事务，所以对事务有要求的业务场景不能使用
表级锁定：其锁定机制是表级索引，这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能
读写互相阻塞：不仅会在写入的时候阻塞读取，MyISAM还会在读取的时候阻塞写入，但读本身并不会阻塞另外的读
只会缓存索引：MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO，但是这个缓存区只会缓存索引，而不会缓存数据

适用场景
不需要事务支持（不支持）
并发相对较低（锁定机制问题）
数据修改相对较少（阻塞问题）
以读为主
数据一致性要求不是非常高

InnoDB
特性
具有较好的事务支持：支持4个事务隔离级别，支持多版本读
行级锁定：通过索引实现，全表扫描仍然会是表锁，注意间隙锁的影响
读写阻塞与事务隔离级别相关
具有非常高效的缓存特性：能缓存索引，也能缓存数据
整个表和主键以Cluster方式存储，组成一颗平衡树
所有Secondary Index都会保存主键信息

适用场景
需要事务支持（具有较好的事务特性）
行级锁定对高并发有很好的适应能力，但需要确保查询是通过索引完成
数据更新较为频繁的场景
数据一致性要求较高
硬件设备内存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，尽
能减少磁盘 IO

下图是我们系统所用的mysql存储引擎

默认是InnoDB引擎，支持事务、行锁和外键

三、数据库的日志系统

从数据库系统结构可知数据库系统中一般都有一个日志系统，它由日志管理服务和日志文件组成的。当我们对数据库进行操作时，数据库系统首先按照一定的规则将你的操作命令和一些附件参数记录到数据库文件日志中，然后在对数据库进行操作，完成所有操作后，在写一些标志到日志文件中。我们现在常用的日志有Undo、Redo还有Undo/Redo等模式
Undo日志
事务开启后，所以事务相关的操作将会写到数据库日志中。如：
1、针对数据的操作，如增加、修改、删除等
2、针对任务的操作，如创建索引，这些任务操作在日志中
记录一个标志，表示执行了这种操作
当回滚任务时，系统自动执行记录的操作的反操作，保证系统的一致性。
系统自动生成一个检查点机制，检查点周期的检查事务日志，如果在事务日志中，事务全部完成，那么检查点将事务日志中的事务全部提交到数据库中，并且在事务日志中做一个检查点提交的标志。如果在事务日志中，如果在事务日志中，事务没有完成，那么检查点将事务日志中的事务不提交到数据库中，并且在事务日志中做一个未提交标志。
检查点的周期是根据用户自定义的时间间隔和系统活动的频度由系统自动计算出的时间间隔

工作原理图：

Redo日志
与Undo的思想相反，这个日志实现记录事务的操作命令、操作队形和对象的新值，然后立即写commit标记，完成一个事务的日志后，将数据写入到数据库中，如果系统崩溃了，在日志中一旦看到commit标记就说明我们准备写盘了，但是我们无法雪顶是否完全写入成功，所以在恢复是我们干脆就在写一次新值，把已经commit的事务重新再做一遍，而那些没有commit标记的事务我们根本不用理睬，因为在系统崩溃前还没有将数据写入盘
检查点重要作用：数据库运行期间定时的写入磁盘，然后在日志中做一个标记，告诉数据库在标记之前的数据已经完全写盘了，以后恢复是不用查看之前的了。具体来说就是定时插入检查点开始标记，在附件参数中记录未完成的事务列表，然后根据日志类型不同，进行不同操作，最后打个检查点结束标记。

如何恢复数据：
Undo日志的恢复是从后向前回滚所有未提交的事务，Redo日志是从前向后重做所有已提交的事务
综上所述我们可知：数据库日志可以保证数据库事务的原子性