MySQL之架构与历史

待我称王封你为后i 2022-05-09 02:22 192阅读 0赞

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

### 文章目录 ###

*  MySQL逻辑架构
 *   *  连接管理与安全性
     *  优化与执行
 *  并发控制
 *   *  读写锁
     *  锁粒度
     *  表锁
     *  行级锁
 *  事务
 *  隔离级别
 *  死锁
 *  事务日志
 *  MySQL中的事务
 *   *  自动提交（AUTOCOMMIT）
     *  在事务中混合使用存储引擎
     *  隐式和显式锁定
 *  多版本并发控制

# MySQL逻辑架构 #

![MySQL逻辑架构图][MySQL]

*  最上层的服务包括连接处理、授权认证、安全等等。
 *  第二层架构是MySQL的核心服务层。包括查询解析、分析、优化、缓存以及所有的内置函数（例如，日期、时间、数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等。
 *  第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。每个存储引擎都有它的优势和劣势。服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎直接的差异。存储引擎API包含几十个底层函数，用于执行诸如“开始一个事务”或者“根据主键提取一行记录”等操作。但存储引擎不会去解析SQL (InnoDB是一个例外，它会解析外键定义，因为MySQL服务器本身没有实现该功能) ，不同存储引擎之间也不会相互通信，而只是简单地响应上层服务器的请求。

## 连接管理与安全性 ##

*  每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或CPU中运行。服务器会缓存线程，因此不需要为每一个创建的连接创建或销毁线程。（MySQL5.5或更高的版本提供了一个API，支持线程池（Thread-Pooling）插件，可以使用池中少量的线程来提供大量的连接。）
 *  当客户端连接到MySQL服务器时，服务器需要对其进行认证。认证时基于用户名、原始主机信息和密码。如果使用了安全套接字（SSL）方式连接，还可以使用X.509证书认证。一旦客户端连接成功，服务器会继续验证该客户端是否具有执行某个特定查询的权限。

## 优化与执行 ##

*  MySQL会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，如重写查询、决定表的读取顺序，以及选择合适的索引等。用户可以通过特殊的关键字提示（hint）优化器，影响它的决策过程。也可以请求优化器解释（explain）优化过程的各个因素，使用户知道服务器时如何进行优化决策的，并提供一个参考基准，便于用户重新构造查询和schema，修改相关配置，使应用尽可能高效运行。
 *  优化器并不关心使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。优化器会要求存储引擎提供容量或某个操作的开销信息、以及表数据的统计信息等。
 *  对于SELECT语句，在解析查询之前，服务器会先检查查询缓存（Query Cache），如果能在其中找到对应的查询，服务器就不会执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集。

# 并发控制 #

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

## 读写锁 ##

*  包括共享锁（shared lock）和排它锁（exclusive lock），也叫读锁（read lock）和写锁（write lock）。
 *  读锁是共享的，或者说是相互不阻塞的。多个客户可以在同一时刻读取同一资源，而互补干扰。写锁是排他的，也就是说一个写锁会阻塞其他的读锁或写锁，这是出于安全策略的考虑，只有这样，才能确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源。
 *  在实际的数据库系统中，每时每刻都在发生锁定，当某个用户在修改某一部分数据时，MySQL会通过锁定防止其他用户读取同一数据。大多数时候，MySQL锁的内部管理都是透明的。

## 锁粒度 ##

*  减少锁的粒度也有助于提高哦共享资源并发性。尽量只锁定需要修改的部分数据，而不是所有的资源。
 *  问题是加锁也需要消耗资源。锁的各种操作，包括获得锁、检查锁是否已经解除、释放锁等，都会增加系统的开销。如果系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能会因此受到影响。
 *  所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡，这种平衡当然也会影响到性能。大多数商业数据库系统没有提供更多的选择，一般都是在表上施加行级锁（row-level lock），并以各种复杂的方式来实现，以便在锁比较多的情况下尽可能地提供更好的性能。

## 表锁 ##

*  表锁是MySQL中最基本的锁策略，并且是开销最小的策略。它会锁定整张表。一个用户在对表进行写操作（插入、删除、更新等）前，需要获取写锁，这会阻塞其他用户对该表的所有读写操作。只有没有写锁时，其他用户才能 获取读锁，读锁之间是不相互阻塞的。
 *  在特定的场景中，表锁也可能有良好的性能。例如，READ LOCAL表锁支持某些类型的并发写操作。另外，写锁比读锁具有更高的优先级，因此一个写锁请求可能会被插入到对锁队列的前面 。
 *  尽管存储引擎可以管理自己的锁，MySQL本身还是会使用各种有效的表锁来实现不同 的目的。例如，服务器会为诸如ALTER TABLE 之类的语句使用表锁，而忽略存储引擎的锁机制。

## 行级锁 ##

*  行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）。在InnoDB和XtraDB，以及其他一下存储引擎中实现了行级锁。行级锁只在存储引擎层实现，而MySQL服务器层没有实现。服务器完全不了解存储引擎中的锁实现。所有的存储引擎都以自己的方式实现了锁机制。

# 事务 #

*  事物是一组原子性的SQL查询，或者说是一个独立的工作单元。事物内的语句，要么全部执行成功，要么全部执行失败。
 *  假如有两张表，假设一个银行的数据库有两张表：支票（checking ）表和储蓄（savings ）表。现在要从用户Jane的支票账户转移200美元到她的储蓄账户，如下  
    可以使用START TRANSACTION语句开启一个事物，然后要么使用COMMIT提交事务将修改的数据持久保留，要么使用ROLLBACK撤销所有的修改。如下

START TRANSACTION; SELECT balance FROM checking WHERE customer_id = 10233276; UPDATE checking SET balance = balance - 200.00 WHERE customer_id = 10233276; UPDATE savings SET balance = balance + 200.00 WHERE customer_id = 10233276; COMMIT;

*  ACID
 *  原子性（atomicity）  
    一个事物必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚。对应一个事物来说，不可能只窒息感其中的一部分操作，这就是事务的原子性。
 *  一致性（consistency）  
    数据库总是从一个一致性的状态转移到另一个一致性的状态。在前面的例子中，一致性确保了，即使在执行第三、四条语句之间时系统崩溃，支票账户中也不会损失200美元，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中。
 *  隔离性（isolation）  
    通常来说，一个事物所做的修改在最终提交之前，对其他事物是不可见的。
 *  持久性(durability)  
    一旦事物提交，其所做的修改就会永久的保存到数据库中，此时即使系统奔溃，修改的数据也不会丢失。
 *  就像锁粒度的升级会增加系统开销一样，这种事务处理过程中额外的安全性，也会需要数据库系统做更多的额外工作。一个实现了ACID的数据库，相比没有实现ACID的数据库，通常会需要更强的CPU处理能力、更大的内存和更多的磁盘空间。

# 隔离级别 #

*  在SQL标准中定义了四种隔离级别，每一种级别都规定了一个事物中所做的修改，那些在事务内和事务间是可见的，那些是不可见的。较低基本的隔离通常可以执行更高的并发，系统的开销也更低。
 *  READ UNCOMMITTED(未提交读)  
    在READ UNCOMMINTTED级别，事务中的修改，即使没有提交，对其他事务也是看见的。事务可以读取未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED 会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。
 *  READ COMMITTED（提交读）  
    大多数数据库系统的默认隔离基本都是READ COMMITTED（但MySQL不是）。READ COMMITTED满足签名提到的隔离性的简单定义：一个事务开始时，只能看见已经提交的事物所做的修改。换句话说，一个事物从开始到结束前，所做的修改对其他事物都是不可见的。这个级别也叫不可重复读（nonrepeatable read），因为两次执行同样的查询，可能会得到不一样的结果。
 *  REPEATABLE READ（可重复读）  
    REPEATABLE READ解决了脏读的问题。该级别保证了在同一个事物中多次读取同样的记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读（Phantom Read）的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行（Phantom Row）。InnoDB和XtraDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读的问题。  
    可重复读是MySQL的默认事务隔离级别。
 *  SERIALIZABLE（可串行化）  
    SERIALIZABLE 是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，SERIALIZABLE 会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。  
    ![隔离级别][70]

# 死锁 #

死锁指两个或更多的事物在同一资源上相互占用，并请求锁定对方持有的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，就可能会产生死锁。多个事务同时锁定同一个资源时，也会产生死锁。  
例如，设想下面两个事务同时处理StockPrice 表：

事务1 START TRANSACTION; UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4 and date = '2002-05-01'; UPDATE StockPrice SET close = 19.80 WHERE stock_id = 3 and date = '2002-05-02'; COMMIT; 事务2 START TRANSACTION; UPDATE StockPrice SET high = 20.12 WHERE stock_id = 3 and date = '2002-05-02'; UPDATE StockPrice SET high = 47.20 WHERE stock_id = 4 and date = '2002-05-01'; COMMIT;

*  如果凑巧，两个事务都执行了第一条UPDATE 语句，更新了一行数据，同时也锁定了该行数据，接着每个事务都尝试去执行第二条UPDATE 语句，却发现该行已经被对方锁定，然后两个事务都等待对方释放锁，同时又持有对方需要的锁，则陷入死循环。除非有外部因素介入才可能解除死锁。
 *  为了解决这种问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误。这种解决方式很有效，否则死锁会导致出现非常慢的查询。还有一种解决方式，就是当查询的时间达到锁等待超时的设定后放弃锁请求，这种方式通常来说不太好。InnoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。
 *  锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则完全是由于存储引擎的实现方式导致的。
 *  死锁发生以后，只有部分或者完全回滚其中一个事务，才能打破死锁。对于事务型的系统，这是无法避免的，所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需要重新执行因死锁回滚的事务即可。

# 事务日志 #

*  事务日志可以帮助提高事务的效率。
 *  使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把修改行为记录到持久在磁盘上的事务日志中，而不用每次将修改的数据本身持久到磁盘上。
 *  事务日志采用的是追加的方式，因此写日志的操作时磁盘上一小块区域的顺序IO，而不想随机IO需要在磁盘的多个地方移动磁头，所有采用事务日志的方式相对来说要快的多。
 *  事务日志持久之后，内存中被修改的数据在后台可以慢慢的刷回到磁盘。目前大多数存储引擎都是这样实现的，我们通常称之为预写式日志（Write-Ahead Logging），修改数据需要写两次磁盘。
 *  如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回到磁盘，此时系统崩溃，存储引擎子在重启时能够自动恢复这部分修改的数据。具体的恢复方式视存储引擎而定。

# MySQL中的事务 #

MySQL提供了两种事务型的存储引擎：InnoDB和NDB Cluster。另外还有一些第三方存储引擎也支持事务，比较知名的包括XtraDB和PBXT。

## 自动提交（AUTOCOMMIT） ##

MySQL默认采用自动提交模式。也就是说，如果不是显式的开启一个事物，则每个查询都被当作一个事务执行提交操作。在当前连接中，可以通过设置AUTOCOMMIT变量来启用或禁用自动提交模式。

*  `1`或`ON`表示启用，`0`或`OFF`表示禁用。当AUTOCOMMIT=0时，所有的查询都在一个事务中，知道显式地执行COMMIT或ROLLBACK，该事务结束，同时又开启了另一个事务。修改AUTOCOMMIT对非事务型的表，比如MyISAM或内存表，不会有任何影响。对这类表来说，没有COMMIT或ROLLBACK的概念，也可以说是相当于一直处于AUTOCOMMIT 启用的模式。
 *  另外还有一些命令，在执行之前会强制执行COMMIT提交当前的活动事务。典型的例子，在数据定义语言（DDL）中，如果是导致大量数据改变的操作，如ALTER TABLE，就是如此。另外还有LOCK TABLES 等其他语句也会导致同样的结果。如果有需要，请检查对应版本的官方文档来确认所有可能导致自动提交的语句列表。
 *  MySQL可以通过执行SET TRANSACTION ISOLATION LEVEL命令来设置隔离级别。新的隔离级别会在下一个事务开始的时候生效。可以在配置文件找那个设置整个数据库的隔离基本，也可以只改变当前会话的隔离级别：

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

MySQL能识别所有的4个ANSI隔离级别，InnoDB引擎也支持所有的隔离级别。

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

*  MySQL服务层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事物中，使用多种存储引擎是不可靠的。
 *  如果在事务中混合使用了事务型和非事务型的表（例如InnoDB和MyISAM表），在正常提交的情况下不会有什么问题。但如果该事务需要回滚，非事务型的表上的变更就无法撤销，这会导致数据库处于不一致的状态，这种情况很难修复，事务的最终结果将无法确定。所以，为每张表选择合适的存储引擎非常重要。
 *  在非事务型的表上执行事务相关操作的时候，MySQL通常不会发出提醒，也不会报错。有时候只有回滚的时候才会发出一个警告：“某些非事务型的表上的变更不能被回滚”。但大多数情况下，对非事务型表的操作都不会有提示。

## 隐式和显式锁定 ##

*  InnoDB采用的是两阶段锁定协议（two-phase locking protocol）。在事务执行的过程中，随时都可以执行锁定，锁只有在执行COMMIT或ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。这些锁都是隐式锁定，InnoDB会根据隔离级别在需要的时候自动加锁。
 *  另外，InnoDB也支持通过特定的语句进行显式的锁定，这些语句不属于SQL规范：

SELECT ... LOCK IN SHARE MODE SELECT ... FOR UPDATE

*  这些锁定经常被滥用，实际上应该尽量避免使用。
 *  MySQL也只支持Lock Tables和Unlock Tables语句，这是在服务层实现的，和存储引擎无关。它们有自己的用途，并不能代替事务处理。如果应用需要用到事务，还是应该选择事务型存储引擎。
 *  经常可以发现，应用语句将表从MyISAM转换到InnoDB，但哈市显示地使用LOCK TABLES语句，这非常没有必要，会严重影响性能，实际上InnoDB的行级锁工作得更好。
 *  LOCK TABLES和事务直接相互影响的话，情况会变得非常复杂。除了在事务中禁用AUTOCOMMIT，可以使用LOCK TABLES外，其他任何时候不要显式地执行LOCK TABLES，不管使用的是什么存储引擎。

# 多版本并发控制 #

*  MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。它们一般都同时实现了多版本并发控制(MVCC)。MVCC没有统一的实现标准，各个数据库系统的实现方式都不一样。
 *  MVCC：可以认为是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低。虽然实现机制不同，但大都实现了非阻塞的读操作，写操作也只锁定了必要的行。
 *  MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的
 *  前面说到不同存储引擎的MVCC实现是不同的，典型的有乐观（optimistic）并发控制和悲观（pessimistic）并发控制
 *  InnoDB的MVVC，是通过在每行记录后面保存两个隐藏列来实现的。一个保存了行的创建时间，一个保存了行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号（system version number）。每开启一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为当前事务的版本号，用来和查询到的每行记录的版本号进行比较。下面看一下在REPEATABLE READ 隔离级别下，MVCC具体是如何操作的：
 *  SELECT  
    InnoDB会根据一下两个条件检查每行记录：

1.  InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于等于当前事务的系统版本号），这样可以确保事务读取的行，要么实在事务开始前就已经存在的，要么是事务自身插入或修改过的。
2.  行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取的行，在事务开始之前未被删除。  
    只有符合上述两个条件的记录，才能作为返回结果。

*  INSERT  
    InnoDB为新插入的每一行保存当前的系统版本号作为行版本号。
 *  DELETE  
    InnoDB为删除的每一行保存当前系统版本号作为行删除标识。只有commit的时候才会真正删除。
 *  UPDATE  
    InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。
 *  保存这两个额外系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。
 *  MVCC只在`REPEATABLE READ`和`READ COMMITTED` 两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容 ，因为READ UNCOMMITTED 总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE 则会对所有读取的行都加锁。

**参考<高性能MySQL>**

[MySQL]: /images/20220509/06c37a923bf94286b56f7f37c6656013.png
[70]: /images/20220509/06694e1146f04f5cab075a84a03872c2.png