MySQL架构

1.1 MySQL逻辑架构

首先看一下MySQL的逻辑架构图。

最上层的的服务端可能是各种各样的应用，需要连接到数据库。
第二层架构包含了MySQL的大多核心服务功能，包括查询解析、分析、优化、缓存以及所有的内置函数（例如，日期、时间、数字和加密函数），所有跨存储引擎的功能都在这一层时间：存储过程、触发器、视图等。
第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。服务器通过API与存储引擎进行通信，这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎API包含几十个底层函数，用于执行诸如“开始一个事务”或者“根据主键提取一行记录”等操作。存储引擎不会去解析SQL，不同存储引擎之间不会相互通信，而只是简单地响应上层服务器的请求。

1.2 并发控制

MySQL中一般讨论两个层面的并发控制：服务器层和存储引擎层。

1.2.1读写锁

这种锁是针对实际应用来设计的，即有些表读操作会占据大部分时间，而只有少部分的写操作，但读操作是不需要对表进行严格加锁的，而只有写操作需要。所以本质上是两种锁：读锁和写锁，又称共享锁和排它锁。

读锁是共享的，多个客户在同一时刻可以同时读取同一个资源，而互不干扰。写锁是排他的，即一个写锁会阻塞其他的写锁和读锁，只有这样，才能保证在给定的时间里，只有一个用户能执行写入且防止其他用户读取正在写入的同一资源。

1.2.2 锁粒度

也就是针对不同规模的数据进行加锁，比如可以对一个表进行加锁，也可以只对表中的某一行进行加锁，让锁定对象更有选择性。理想情况当然是只对修改的数据片进行精确的锁定。但锁管理会消耗大量资源，所以将锁粒度固定在某个级别，可以为特定场景提供更好的功能。接下来介绍两种最重要的锁策略

表锁

表锁是MySQL中最基本的锁策略，且开销最小。它会锁定整张表，对表进行写操作时获取写锁，这会阻塞其他用户对该表的所有读写操作。而没有写锁时，其他用户才能获取到读锁，不同用户获取的读锁之间是不互相阻塞的。写锁通常来说相较于读锁有更高的优先级。

行级锁

行级锁可以最大程度地支持并发处理（也带来了最大的锁开销），行级锁只在存储引擎层实现，而MySQL服务器层没有实现。服务器层完全不了解存储引擎中的锁实现。

1.3 事务

事务就是一组原子性的SQL查询，也就是说事务内的语句，要么全都执行成功，要么全部执行失败。事务有四个特性ACID，即原子性（atomicity）、一致性（consistency）、隔离性（isolation）、持久性（durability）。银行应用能很好地解释事务必要性，现在就拿转账的例子，用户A给用户B转账200美元，一般需要三个步骤：

1. 检查用户A账户余额高于200美元。
2. 从用户A的账户中减去200美元。
3. 用户B的账户中增加200美元。

这三个步骤必须打包在一个事务内，任何一个步骤失败，则须回滚所有的步骤。
在MySQL中用START TRANSACTION语句开始一个事务，然后要么使用COMMIT提交事务将修改的数据持久保留，要么使用ROLLBACK撤销所有的修改。语句如下：

1  START TRANSACTION;
2  SELECT balance FROM account WHERE account_id='A';
3  UPDATE account SET balance = balance - 200 WHERE account_id='A';
4  UPDATE account SET balance = balance + 200 WHERE account_id='B';
5  COMMIT;

接下来简述一下各个特性具体代表什么：

原子性

一个事物被视为一个不可分割的最小工作单元，整个事务中所有操作要么全部调教成功，要么全部失败混滚，不可能只执行其中的一部分操作。

一致性

数据库总是从一个一致性的状态转换到另一个一致性的状态。例如即使在执行第三、四条语句之间时发生了系统崩溃，A用户也不会失去200元，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中。

隔离性

通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。即若执行完语句3但还未开始执行4的时候，另一个账户汇总程序看到的用户A的账户中余额并没有减去200元。因为整个事务还未执行完，所以其中的改变对于其他事务是不可见的。

持久性

一旦事务提交，则其所做的修改就会永久保存到数据库中。

1.3.1 隔离级别

隔离是针对于不同的事务来说的，每一种级别都规定了一个事务所做的修改，哪些在事务内和事务间是可见的，哪些是不可兼得。较低级别的隔离通常可以执行更高的并发，系统的开销也更低。接下来介绍四种隔离级别：

READ UNCOMMITTED（未提交读）

这个级别中，事务中的修改即使没有提交，对其他事务也都是可见的。事务可以提交未提交的数据，这也被成为脏读。这个级别性能不高，而且会出现很多问题，很少使用。

READ COMMITTED（提交读）

这是大多数据库默认隔离级别（但MySQL不是）。这个级别的定义：一个事务开始时，只能“看见”已经提交得到事务所做的修改，即一个事务从开始直到提交前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫作不可重复读，因为两次执行同样的查询，可能会得到不一样的结果。

REPEATABLE READ（可重复读）

它解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。但是它理论上无法解决脏读的问题。脏读就是当某个事物在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围内的记录时，会产生幻行。
它是MySQL的默认事务隔离级别。

SERIALIZABLE（可串行化）

它是最高的隔离级别，他通过强制事务串行执行，避免了幻读的问题。SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题，所以也很少使用。

隔离级别	脏读可能性	不可重复读可能性	幻读可能性	加锁读
READ UNCOMMITTED	YES	YES	YES	NO
READ COMMITTED	NO	YES	YES	NO
REPEATABLE READ	NO	NO	YES	NO
SERIALIZABLE	NO	NO	NO	YES

1.3.2 死锁

死锁就是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。为解决这个问题，数据库系统实现了各种死锁监测和死锁超时机制。比如InnoDB存储引擎检测到死锁的循环依赖，并立即返回一个错误，这样避免了查询慢；还有就是当查询的时间达到锁等待超时的设定后放弃锁清秋。InnoDB存储引擎处理死锁的方法是，将持有最少行级排它锁的事务进行回滚。死锁发生以后，只有部分或者完全回滚其中一个事务，才能打破死锁。所以对于事务型的系统，设计的时候必须考虑如何处理死锁，大多情况下只需要重新执行因死锁回滚的事务即可。

1.3.3 事务日志

使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把修改行为记录持久在硬盘的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用的追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快的多。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘，这也叫预写式日志，因此修改数据需要写两次磁盘（日志和真正的数据）。

1.3.4 MySQL中的事务

MySQL提供了两种事务型的存储引擎：InnoDB和NDB Cluster。

自动提交（AUTOCOMMIT）

MySQL默认使用自动提交模式。也就是说，如果不是显式地开始一个事务，则每个查询都被当做一个事务执行提交操作。可通过设置AUTOCOMMIT变量来启用或者禁用自动提交模式，1或者ON代表启用，0或者OFF代表禁用。当AUTOCOMMIT=0时，所有的查询都是在一个事务中，直到显式地执行COMMIT提交或者ROLLBACK回滚，该事务结束，同时又开始了另一个新事务。修改AUTOCOMMIT对于非事务型的表不会有任何影响。

还有一些命令，在执行之前会强制执行COMMIT提交当前的活动事务，例如像ALTER TABLE这样会导致大量数据改变的操作，或者LOCK TABLES等。

MySQL可通过执行SET TRANSACTION ISOLATION LEVEL命令设置隔离级别，新的隔离级别会在下一个事务开始的时间生效。可在配置文件中设置整个数据库的隔离级别，也可只改变当前会话的隔离界别。

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

MySQL服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中使用多种存储引擎是不可靠的。有时在一个事务中会混合使用事务型和非事务型的表（即每个表使用不同的存储引擎存储），一般没什么问题，但如果该事务需要回滚，非事务型的表上的变更就无法撤销，就会导致数据库处于不一致的状态，事务的最终结果将无法确定。所以，为每张表选择合适的存储引擎非常重要。

在非事务型的表上执行事务相关操作的时候，MySQL通常不会发出提醒和报错。

1.4 多版本并发控制（比较重要）

MySQL的大多事务型存储引擎实现的都不是简单地行级锁，考虑性能方面会同时实现多版本并发控制（MVCC）。它在很多情况下避免了加锁操作，开销更低，且大都实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。下面看一下MVCC是如何工作的：
InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。可以看一下在REPEATABLE READ隔离级别下，MVCC具体是如何操作的。

• SELECT：InnoDB会根据一下两个条件检查每行记录：

  1. InnoDB只查找版本早于当前事务 的数据行（也就是行的系统版本号小于或等于事务的系统版本号），这样就可以确保事务读取的行，==要么在事务开始前就已经存在的，要么是事务自身插入或者修改过的。
  2. 行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。

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

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

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

所以能看出来，其实它删除了一行数据，只是保存了一个版本号，同样UPDATE操作也是通过插入一个新行的方法，而不是完全抹除原来的行，所以虽然有一些多余数据的存储，但是提高了并发性。

保存这两个额外系统版本号，是大多数读操作都可以不用加锁，性能较好，且能保证只读到符合标准的行。不足之处就是每行记录都需要额外的存储空间，需要做额外的检查和维护工作。

要知道MVCC只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容，因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行，SERIALIZABLE则会对所有读取的行都加锁。