MySQL之架构简述概述MySQL逻辑架构并发控制事务多版本并发控制MySQL存储引擎总结

概述

MySQL最与众不同的特性是其存储引擎架构，这种架构的设计将查询处理（Query Processing）及其他系统任务（Server Task）和数据的存储/提取相分离。这种处理和存储分离的设计可以在使用时根据性能，特性，以及需求来选择数据存储的方式

MySQL逻辑架构

MySQL的逻辑架构图如下：

最上层的服务并不是MySQL独有的，大多数基于网络的客户端/服务器的工具都有类似的架构。比如连接，授权认证，安全等

第二层架构是MySQL的核心部分，大部分的核心功能在第二层中，包括查询，分析，优化，缓存以及所有的内置函数（例如，日期，时间，数学和加密函数），所有的跨存储引擎的功能都在这一层实现：存储过程，触发器，视图。

第三层包括存储引擎，存储引擎负责MySQL中数据的存储和提取。服务器通过API与存储引擎之间进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎API包含几十个底层函数，用于执行诸如“开始一个事务”或者“根据主键提取一行记录”等操作，但是存储引擎不会解析SQL，不同的存储引擎之间也不会相互通信，而只是简单相应上层服务器的请求

连接管理和安全性

每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在单独的线程中执行。

当客户端连接到MySQL服务器时，服务器需要对其进行认证。认证基于用户名，密码等信息。如果使用安全套接字（SSL）的方式连接，可以使用安全证书。一旦客户端连接成功，服务器会继续验证该客户端是否具有执行某个特定查询的权限

优化与执行

MySQL会解析查询，并且创建内部数据结构（解析树），然后对其进行优化，包括重写查询，决定表的读取顺序，选择合适的索引等等。用户可以通过特殊的关键字提示（hint）优化器，影响它的决策过程。也可以请求优化器解释（explain）优化过程的各个因素，使用户可以直到服务器是如何进行优化决策的，以便用户重构查询和schema，修改相关配置，使应用尽可能高效运行。

优化器并不关心表使用的什么引擎，但存储引擎对于优化查询是有影响的。优化器会请求存储提供容量或者某个具体操作的开销信息，以及表数据的统计信息。对于SELECT语句，在解析查询之前，服务器会先检查缓存（Query Cache），如果能在其中找到对应的查询，服务器就不必在执行查询解析。而是直接返回查询缓存中的结果集。

并发控制

无论何时，只要有多个查询就需要在同一时刻修改数据，产生并发控制问题。在两个层面上谈论并发控制：服务层和存储引擎层。

以unix系统的email box为例，典型的mbox文件格式非常简单。一个mbox邮箱中所有的邮件都串行在一起，彼此首位相连。这种格式对于读取和分析邮件信息非常友好。同时投递邮件也很容易，只要在文件末尾加上新的邮件内容即可。如果两个进程同一时刻对同一个邮箱进行投递邮件，邮箱的数据就会被破坏，两封邮件的内容会交叉附加在邮箱文件末尾

读写锁

把上述邮箱当作数据库中的一个表，把邮件当作表中的一行记录，就很容易看出问题。解决这类问题的经典方法就是并发控制。在处理并发读或者写时可以实现一个由两种类型锁组成的所系统来解决问题。这两种类型的锁通常被称为共享锁（shared lock）和排他锁（exclusive lock），也叫读锁（read lock）和写锁（write lock）

锁粒度

一种提高共享资源并发方式就是让锁对象更具有选择性。尽量只锁定需要修改的部分，而不是所有的资源。所谓的锁策略，就是在锁的开销和数据安全性之间寻求平衡，这种平衡当然会影响到性能。MySQL存储引擎可以实现自己的锁策略和锁粒度。在存储引擎的设计中，锁管理是个非常重要的决定。将锁粒度固定在某个级别，可以为某个特定应用场景提供更好的性能。下面介绍两种锁策略

表锁（table lock）

表锁是MySQL最基本的锁策略，并且是开销最小的策略。它会锁定这张表整张表。一个用户在进对表进行写操作（插入，删除，更新等）前，需要获得写锁，这会阻塞其他用户对该表的所有读写操作。只有没有写锁的时候，其他读取的用户才能获得读锁，读锁之间是不互相阻塞的。

在特定的场景中，表锁也有良好的性能。例如，READ,LOCAL表锁支持某些类型的并发操作，另外，写锁也比读锁有更高级的优先级，因此一个写锁请求可能会被插入到读锁队列前面，读锁不会插入到写锁的前面。尽管存储引擎可以管理自己的锁，MySQL本身还会使用各种有效的表锁来实现不同的目的。例如，服务器会为ALTER,TABLE之类的语句使用表锁，而忽略存储引擎的锁机制。

行锁

行锁可以最大限度的支持并发处理，当然锁的开销也是最大的。行锁只在存储引擎层实现，而MySQL服务器层没有实现。雾浮起不了解存储引擎中的所实现，所有的存储引擎都有自己的方式显示了锁机制

事务

事务日志

事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改记录到持久在硬盘的事务日志上，，而不用每次都将修改的数据本身持久化到磁盘。事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块内的顺序I/O，而不是随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对爱说要快得多。事务日志持久化以后，内存中被修改的数据在后台慢慢刷回磁盘。我们通常称之为预写式日志（Write-Ahead-Logging）,修改数据需要写两次磁盘

如果数据的修改已经记录到事务日志并且持久化了，但数据本身还没有回写磁盘，这时系统崩溃，存储引擎在重启时能自动恢复这部分修改的数据，具体的恢复方式视存储引擎而定

MySQL中的事务

自动提交

MySQL默认采用自动提交模式。也就是说，如果不是显示地开始一个事务，每个查询都被当作一个事物执行提交操作。当前连接中，可以设置AUTOCOMMIT变量来开启或者禁用自动提交模式：1或者ON表示启用，0或者OFF表示禁用，所有的查询都在一个事务中，直到显示地执行COMMIT或者ROLLBACK回滚，该事务结束，又开启新的事务。

多版本并发控制

MVCC可以看作是一个行级锁的变种，但是它在很多情况下避免了加锁的操作，因此开销更低。实现了非阻塞的读，写操作也只锁定必要的行。MVCC实现通过保存数据在某个时间点的快照实现，也就是说，不管执行行多长时间，每个事务看到的数据都是一致的。

InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存了行的过期时间（或者删除时间）。当然存储的并不是实际的时间值，而是系统版本号（system version number），每开始一个新事物，系统版本号自动递增。事务开始时刻的版本还会作为事务版本号，用来和查询到的每行记录的版本号比较。

MVCC在REPEATABLE READ和READ COMMITTED两个隔离级别下工作，其他的两个隔离界别与MVCC不兼容。这样设计使读数据操作简单，性能很好，并且也能保证读取到的是符合标准的行。REPEATEDABLE READ隔离级别下，MVCC操作如下：

SELECT
InoDB会根据以下两个条件检查每个记录：

• a.InnoDB只查找版本早于当前事务版本号的数据行（行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么在事务开始之前已经存在，要么是事务自身插入或者修改的

• b.行的删除版本要么未定义，要么大于当前事务版本号。可以确保事务读取到的行，在事务开始之前未被删除

  只有符合上面两个条件的记录，才会被删除

INSERT
InnoDB为新插入的每行保存当前系统版本号作为行版本号

DELETE
InnoDB为删除的每个行保存当前系统版本号作为行删除标识

UPDATE
InnoDB为插入一行新记录，保存当前系统版本号作为删除标识，同时奥村当前系统版本号到原来的行作为删除标识

MySQL存储引擎

在文件系统中，MySQL为每个数据库保存为数据目录下的一个子目录。创建表时，MySQL会在数据库子目录下创建一个和表同名的.frm文件保存表的定义。表的定义在MySQL服务层统一处理

InoDB存储引擎

InnoDB数据存储在表空间（tablespace）中，表空间是由InnoDB管理的黑盒子，有一系列数据文件组成。InnoDB将每个表的数据和索引分别存放在单独的文件中，InnoDB采用MVCC来支持高并发，并且实现了四个标准的隔离级别。默认级别是REPEATEDABLE READ（可重复读），并且通过间隙锁（next-key locking）防止幻读的出现，间隙锁使得InnoDB不仅锁定查询涉及的行，还会对索引中的间隙进行锁定，以防止幻影行的插入

InnoDB表基于聚簇索引建立的，InnoDB的索引结构和MySQL的其他存储引擎不同，聚簇索引对主键查询有很高的性能。不过它的二级索引（非主键索引）中必须包含主键列，所以如果主键列很大，那么其他索引也会很大。

MyISAM存储引擎

MyISAM提供了大量的特性，包括全文索引，压缩，空间函数，但是MyISAM不支持事务和行级锁，所以崩溃后无法安全恢复。尽管不支持事务，崩溃无法安全恢复，但对于只读数据，或者表小的情况，是可以使用MyISAM的。MyISAM会将表存储在两个文件：数据文件和索引文件，分别以.MYD和.MYI为扩展名

总结

MySQL拥有分层的架构，上层是服务器的服务和查询执行引擎，下面是存储引擎。虽然有很多不同作用的插件API，但是存储引擎API还是最重要的。理解MySQL在存储引擎和服务层之间处理查询时如何通过API进行交互，就能抓住MySQL的核心基础架构的精髓

最后

以上就是高兴发夹为你收集整理的MySQL之架构简述概述MySQL逻辑架构并发控制事务多版本并发控制MySQL存储引擎总结的全部内容，希望文章能够帮你解决MySQL之架构简述概述MySQL逻辑架构并发控制事务多版本并发控制MySQL存储引擎总结所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。