mysql 的逻辑架构 与 存储引擎的介绍

mysql 的逻辑架构分为三层：

最上层的服务大多数基于网络的客户端、服务器的工具或者服务都有类似的架构，比如连接处理，授权认证、安全等

第二层架构：mysql的核心服务功能都在这一层，包括查询解析，分析，优化，缓存以及所有的内置函数，所有跨存储引擎的功能都在这一层实现：存储过程，触发器、视图

第三层：包含存储引擎。负责数据的存储和提取，innodb是个例外，它会解析外键定义，因为mysql服务器本身没有实现该功能

连接管理与安全性：

当客户端连接到mysql服务器是，服务器需要对其进行认证，认证基于用户名，原始主机信息和密码，一旦客户端连接成功，服务器 会继续验证该客户端是否具有执行某个特定查询的权限

优化与执行：

mysql会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询，决定表的读取顺序，以及选择合适的索引，用户可以通过特殊的关键字提示优化器，影响他的决策过程，也可以请求优化器解释优化过程的各个因素，使yoghurt可以知道服务器是如何进行优化决策的，并提供一个参考基准，便于用户重构查询和修改相关配置，优化查询效率

存储引擎对于优化查询时有影响的

对于select语句，在解析查询之前，服务器会先检查缓存，如果能找到对应的查询，服务器就不会再执行查询解析，优化和执行的整个过程，而是直接返回查询结果

并发控制：

只要有多个查询需要在同一时刻修改数据，都会产生并发控制的问题。

如果应用锁可以保证数据的完整性，不被破坏，但是并不支持并发处理。

两个层面的并发控制：服务器层和存储引擎层

读写锁：通过实现一个由两种类型的锁组成的锁系统来解决问题，也称作共享锁和排它锁或者读锁和写锁

读锁是共享的，互相不阻塞的，而写锁则是排他的，

锁粒度：一种提高共享资源并发性的方式就是让锁定对象更有选择性，尽量只锁定需要修改的部分数据，而不是所有资源。更理想的方式是，是对会修改的数据片进行精确的锁定，

在任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可

所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡，大多数商业数据库系统没有提供能多的选择，一般都是在表上施加行级锁，而mysql则提供了多种选择，每种mysql存储引擎都可以实现自己的锁策略和锁粒度

表锁：

锁开销最小的策略，会锁定整张表，写锁也比读锁优先级更高，一个写锁请求可能会被插入到读锁队列的前面

行级锁：

最大程度地支持并发处理，同时也带来最大的锁开销，行级锁只在存储引擎层实现，服务器层没有实现，所有的引擎都以自己的方式实现了锁

事务：acid

atomicity consistency isolation durability

每种存储引擎实现的隔离级别不尽相同

四种隔离级别：innodb引擎支持所有隔离级别

read uncommitted：未提交读，事务可以读取未提交的数据，脏读（很少使用）

read committed：提交读，大多数数据库系统的默认隔离级别都是read committed，但mysql不是，这和个级别有时候也叫做不可重复读，两次执行同样的查询可能会得到不一样的结果

repeatable read：可重复读，是mysql的默认事务隔离级别，该级别保证了在同一个事务中多次读取同样的记录结果是一致的。但是无法解决另外一个幻读问题。幻读指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，档之前的事务再次读取该范围的记录时，会产生幻行。

innodb和xtradb存储引擎通过多版本并发控制解决了幻读的问题。

serializable：可串行化，最高的隔离级别，强制事务串行执行，避免幻读问题。也很少用。

事务日志;

帮助提高事务的效率，使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘，事务日志采用的追加的方式，因此写日志的操作时磁盘上一小块区域内的顺序i/o操作，而不像随机i/o需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说快的多

修改数据需要写两次磁盘

mysql中的事务

两种事务型的存储引擎：innodb和ndb cluster

set autocommit = 0 ;设置禁用自动提交模式，修改autocommit对本身就是非事务型的表，不会有任何影响。

有些命令在执行之前会强制执行commit提交当前的活动事务。

set transaction isolation level read committed；设置隔离级别。可以在配置文件中设置整个数据库的隔离级别，也可以只改变当前会话的隔离级别

在事务中混合使用存储引擎

mysql服务器层不管理事务，事务是由下层的存储引擎实现的，所以在同一个事务中，使用多种存储引擎是不可靠的

mvcc：多版本并发控制

innodb的mvcc:通过在每行记录后面保存两个隐藏的列来实现的，一个列保存了行的创建时间，一个保存行的过期时间（删除时间），存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。

不同的存储引擎保存数据和索引的方式是不同的，但表的定义则是在mysql服务层统一处理的

show table status like 'user';显示相关表信息

innodb是mysql的默认事务型引擎，被设计用来处理大量的短期事务，短期事务大部分情况是正常提交的，很少会被回滚，

innodb

innodb基于聚簇索引建立，innodb的索引结构和mysql的其他存储引擎有很大的不同，聚簇索引对主键查询有很高的性能，不过它的二级索引中必须包含主键列，若表上的索引较多的话，主键应当尽可能小。存储格式是平*立的，可移植。崩溃后可安全恢复

myisam存储引擎;崩溃后无法恢复。支持数据修复，支持全文索引，基于分词创建的索引，对整张表加锁，写锁具有排他性，读锁共享，不能很好的支持高并发

memory引擎：基于内存，所以不保存数据 ，支持hash索引，是表级锁，并发写入性能较低， 应用场景：用于保存数据分析中产生 的中间数据，用于查找或者映射表，mysql在执行查询的过程中需要使用临时表来保存中间结果，内部使用的临时表就是memory表。

ndb cluster引擎：

mysql服务器、ndb集群存储引擎，以及分布式的，share-nothing的，容灾的，高可用的ndb数据库的组合，被称为mysql集群。

第三方存储引擎：

oltp：xtradb是基于innodb引擎的一个改进版本，可以作为innodb的一个完全的替代产品。

另外还有一些和innodb非常类似的oltp类存储引擎，比如都支持acid事务和mvcc,其中一个就是pbxt。对固态存储ssd提供了适当的支持。

tokudb引擎使用了一种新的叫做分形树的索引数据结构，该结构是缓存无关的，因此即使其大小超过内存性能也不会下降，是一种大数据存储引擎，因为拥有很高的压缩比，可以在很大的数据量上创建大量索引 。

面向列的存储引擎：

mysql默认是面向行的，服务器的查询也是以行为单位处理的，

infobright是最有名的面向列的存储引擎，在非常的数据量（数十tb）时，该引擎工作良好。视为数据分析和数据仓库应用设计的。数据高度压缩，按照块进行排序，每个块都对应一组元数据。访问元数据即可决定是否跳过该块，该引擎不支持缩影。

参考文献《高性能mysql》