高性能MySQL读书笔记-事务

1、MySQL逻辑架构

为了充分发挥MySQL的性能并顺利地使用，就必须理解其设计。

1. 逻辑架构

最上层的服务并非MySQL所独有的，大多数基于网络的客户端/服务器的工具或者服务都有相似的架构。好比链接处理、受权认证、安全等等。

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

第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。和GNU/Linux下的各类文件系统同样，每一个存储引擎都有它的优点和劣势。服务器经过API与存储引擎进行通讯。这些接口屏蔽了不一样存储引擎之间的差别，使得这些差别对上层的查询过程透明。存储引擎不会去解析SQL（InnoDB是一个例外，它会去解析外键定义，由于MySQL服务器自己没有实现该功能），不一样存储引擎之间也不会相互通讯，而只是简单的响应上层服务器的请求。

2. 链接管理和安全性

每一个客户端链接都会在服务器进程中拥有一个线程，这个链接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责缓存线程，所以不须要为每个新建的链接建立或者销毁线程。

认证基于用户名、原始主机信息和密码。若是使用了安全套接字（SSL）的方式链接，还可使用X.509证书认证。一旦客户端链接成功，服务器会继续验证该客户端是否具备执行某个特定查询的权限。

3. 优化与执行

MySQL会解析查询，并建立内部数据结构（解析树），而后对其进行各类优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。用户能够经过特殊的关键字提示（hint）优化器，影响它的决策过程。也能够请求优化器解释（explain）优化过程的各个因素，使用户能够知道服务器是如何进行优化决策的，并提供一个参考基准，便于用户重构查询和schema、修改相关配置，使应用尽量高效运行。

优化器并不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。优化器会请求存储引擎提供容量或某个具体操做的开销信息，以及表数据的统计信息等。

对于SELECT语句，在解析查询以前，服务器会先检查查询缓存（Query Cache），若是可以在其中找到对应的查询，服务器就没必要再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集。

高性能MySQL: 第3版/(美)施瓦茨等著, 宁海元等译, 北京: 电子工业出版社, 2013.5, 第1-3页。

2、并发控制

不管什么时候，只要有多个查询须要在同一时刻修改数据，都会产生并发控制问题。

1. 读写锁

同一时刻多个用户并发读取也不会有什么问题，由于读取不会修改数据，因此不会出错。但读取的过程当中若是有修改，也可能会读取到不一致的数据，为了安全起见，即便是读取也须要特别注意。

解决这类经典问题的方法就是并发控制，其实很是简单。在处理并发读或者写时，能够经过实现一个由两种类型的锁组成的锁系统来解决问题。这两种类型的锁一般被称为共享锁（shared lock）和排他锁（exclusive lock），也叫读锁（read lock）或写锁（write lock）。

读锁是共享的，或者说是相互不阻塞的。多个客户在同一时刻能够同时读取同一个资源，而互不干扰。写锁则是排他的，也就是说一个写锁会阻塞其它的写锁和读锁，这是出于安全策略的考虑，只有这样，才能确保在给定的时间里，只有一个用户能执行写入，并防止其余用户读取正在写入的同一资源。

2. 锁粒度

一种提升共享资源并发性的方式就是让锁定对象更有选择性。尽可能只锁定须要修改的部分数据，而不是全部的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任什么时候候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突便可。

问题是加锁也须要消耗资源。锁的各类操做，包括得到锁、检查锁是否已经解除、释放锁等，都会增长系统的开销。若是系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能会所以受到影响。

所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡，这种平衡固然也会影响到性能。大多数商业数据库系统没有提供更多的选择，通常都是在表上施加行级锁（row-level lock），并以各类复杂的方式来实现，以便在锁比较多的状况下尽量地提供更好的性能。

而MySQL则提供了多种选择。每种MySQL存储引擎均可以实现本身的锁策略和锁粒度。在存储引擎的设计中，锁管理是个很是重要的决定。将锁粒度固定在某个级别，能够为某些特定的应用场景提供更好的性能，但同时却会失去对另一些应用场景的良好支持。好在MySQL支持多个存储引擎的架构，因此不须要单一的通用解决方案。

2.1 表锁（table lock）

表锁是MySQL中最基本的锁策略，而且是开销最小的策略。一个用户在对表进行写操做（插入、删除、更新等）前，须要先得到写锁，这会阻塞其余用户对该表的全部读操做。只有没有写锁时，其余读取的用户才能得到读锁，读锁之间是不相互阻塞的。

在特定的场景中，表锁也可能有良好的性能。写锁也比读锁有更高的优先级，所以一个写锁请求可能会被插入到读锁队列的前面。

服务器会为诸如 ALTER TABLE 之类的语句使用表锁，而忽略存储引擎的锁机制。

2.2 行级锁（row lock）

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

高性能MySQL: 第3版/(美)施瓦茨等著, 宁海元等译, 北京: 电子工业出版社, 2013.5, 第3-5页。

3、事务

事务就是一组原子性的SQL查询，或者说一个独立的工做单元。若是数据库引擎可以成功地对数据库应用该组查询的所有语句，那么就执行该组查询。若是其中有任何一条语句由于崩溃或者其它缘由没法执行，那么全部的语句都不会执行。也就是说，事务内的语句，要么所有执行成功，要么所有执行失败。

单纯的事务概念并非故事的所有。除非系统经过严格的ACID测试，不然空谈事务的概念是不够的。ACID表示原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。一个运行良好的事务处理系统，必须具有这些标准特征。

原子性（atomicity）

一个事务必须被视为一个不可分割的最小工做单元，整个事务中的全部操做要么所有提交成功，要么所有失败回滚，对于一个事务来讲，不可能只执行其中的一部分操做，这就是事务的原子性。

一致性（consistency）

数据库老是从一个一致性的状态转换到另外一个一致性的状态。

隔离性（isolation）

一般来讲，一个事务所作的修改在最终提交之前，对其它事务是不可见的。

持久性（durability）

一旦事务提交，则其所作的修改就会永久保存到数据库中。此时即便系统崩溃，修改的数据也不会丢失。持久性是个有点模糊的概念，由于实际上持久性也分不少不一样的级别。有些持久性策略可以提供很是强的安全保障，而有些则未必。并且不可能有能作到100%的持久性保证的策略。

一个兼容ACID的数据库系统，须要作不少复杂但可能用户并无察觉到的工做，才能确保ACID的实现。

就像锁粒度的升级会增长系统的开销同样，这种事务处理过程当中额外的安全性，也会须要数据库系统作更多的额外工做。一个实现了ACID的数据库，相比没有实现ACID的数据库，一般须要更强的CPU处理能力，更大的内存和更多的磁盘空间。用户能够根据业务是否须要事务处理，来选择合适的存储引擎。对于一些不须要事务的查询类应用，选择一个非事务型的存储引擎，能够得到更高的性能。即便存储引擎不支持事务，也能够经过 LOCK TABLES 语句为应用提供必定程度的保护，这些选择用户均可以自主决定。

1. 隔离级别

隔离性其实比想象的要复杂。在SQL标准中定义了四种隔离级别，每一种级别都规定了一个事务中所作的修改，哪些在事务内和事务间是可见的，哪些是不可见的。较低级别的隔离一般能够执行更高的并发，系统的开销也更低。

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

READ UNCOMMITTED（未提交读）

在 READ UNCOMMITTED 级别，事务中的修改，即便没有提交，对其它事务也都是可见的。事务能够读取未提交的数据，这也被称为脏读（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 会在读取的每一行数据上都加锁，因此可能致使大量的超时和锁争用的问题。实际应用中也不多用到这个隔离级别，只有在很是须要确保数据的一致性并且能够接受没有并发的状况下，才考虑采用该级别。

表 ANSI SQL 隔离级别

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

2. 死锁

死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而致使恶性循环的现象。当多个事务试图以不一样的顺序锁定资源时，就可能会产生死锁。多个事务同时锁定同一个资源时，也会产生死锁。例如，设想下面两个事务同时处理 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目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。

锁的行为和顺序是和存储引擎相关的。以一样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重缘由：有些是由于真正的数据冲突，这种状况一般很难避免，但有些则彻底是因为存储引擎的实现方式致使的。

死锁发生之后，只有部分或者彻底回滚其中一个事务，才能打破死锁。对于事务型的系统，这是没法避免的，因此应用程序在设计时必须考虑如何处理死锁。大多数状况下只须要从新执行因死锁回滚的事务便可。

3. 事务日志

事务日志能够帮助提升事务的效率。使用事务日志，存储引擎在修改表的数据时只须要修改其内存拷贝，再把该修改行为记录到持久在磁盘上的事务日志中，而不用每次都将修改的数据自己持久到磁盘。事务日志采用的是追加的方式，所以写日志的操做是磁盘上一小块区域内的顺序 I/O，而不像随机 I/O 须要在磁盘的多个地方移动磁头，因此采用事务日志的方法相对来讲要快得多。事务日志持久之后，内存中被修改的数据在后台能够慢慢地刷回到磁盘。目前大多数存储引擎都是这样实现的，咱们一般称之为预写式日志（Write-Ahead Logging），修改数据须要写两次磁盘。

若是数据的修改已经记录到事务日志并持久化，但数据自己尚未写回磁盘，此时系统崩溃，存储引擎在重启时可以自动恢复这部分修改的数据。

4. MySQL 中的事务

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

自动提交（AUTOCOMMIT）

MySQL 默认采起了自动提交（AUTOCOMMIT）模式。也就是说，若是不是显式地开始一个事务，则每一个查询都被当作一个事务执行提交操做。在当前链接中，能够经过设置 AUTOCOMMIT 变量来启用或者禁用自动提交模式：

zhgxun-pro:notes zhgxun$ mysql.server start
Starting MySQL
 SUCCESS! 
zhgxun-pro:notes zhgxun$ 
zhgxun-pro:notes zhgxun$ mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.18 Homebrew

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show variables like 'AUTOCOMMIT';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.01 sec)

mysql> SET AUTOCOMMIT = 1;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'AUTOCOMMIT';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.00 sec)

mysql> SET AUTOCOMMIT = 0;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'AUTOCOMMIT';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | OFF   |
+---------------+-------+
1 row in set (0.01 sec)

mysql> SET AUTOCOMMIT = 1;
Query OK, 0 rows affected (0.00 sec)

mysql> quit
Bye
zhgxun-pro:notes zhgxun$ mysql.server stop
Shutting down MySQL
.. SUCCESS! 
zhgxun-pro:notes zhgxun$

1或者 ON 表示启用，0或者 OFF 表示禁用。当 AUTOCOMMIT=0 时，全部的查询都是在一个事务中，直到显示地执行 COMMIT 提交或者 ROLLBACK 回滚，该事务结束，同时又开始了另外一个新事务。修改 AUTOCOMMIT 对非事务型的表，好比 MyISAM 或者内存表，不会有任何影响。对这类表来讲，没有 COMMIT 或者 ROLLBACK 的概念，也能够说是至关于一直处于 AUTOCOMMIT 启用的模式。

另外还有一些命令，在执行以前会强制执行 COMMIT 提交当前的活动事务。典型的例子，在数据定义语言（DDL）中，若是是会致使大量数据改变的操做，好比 ALTER TABLE，就是如此。另外还有 LOCK TABLES 等其余语句也会致使一样的结果。若是有须要，请检查对应版本的官方文档来确认全部可能致使自动提交的语句列表。

MySQL 能够经过执行 SET TRANSCTION ISOLATION LEVEL 命令来设置隔离级别。新的隔离级别会在下一个事务开始的时候生效。能够在配置文件中设置整个数据库的隔离级别，也能够只改变当前会话的隔离级别：

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

MySQL 可以识别全部的4个 ANSI 隔离级别，InnoDB 引擎也支持全部的隔离级别。

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

MySQL 服务器层无论理事务，事务是由下层的存储引擎实现的。因此在同一个事务中，使用多种存储引擎是不可靠的。

若是在事务中混合使用了事务型和非事务型的表（例如 InnoDB 和 MyISAM 表），在正常提交的状况下不会有什么问题。

但若是该事务须要回滚，非事务型的表上的变动就没法撤销，这会致使数据库处于不一致的状态，这种状况很难修复，事务的最终结果将没法肯定。因此，为每张表选择合适的存储引擎很是重要。

在非事务型的表上执行事务相关的操做的时候，MySQL 一般不会发出提醒，也不会报错。有时候只有回滚的时候才会发出一个警告：“某些非事务型的表上的变动不能被回滚”。但大多数状况下，对非事务型表的操做都不会有提示。

隐式和显示锁定

InnoDB 采用的是两阶段锁定协议（two-phase locking protocol）。在事务执行过程当中，随时均可以执行锁定，锁只有在执行 COMMIT 或者 ROLLBACK 的时候才会释放，而且全部的锁是在同一时刻被释放。

另外，InnoDB 也支持经过特定的语句进行显式锁定，这些语句不属于SQL规范，这些锁定提示常常被滥用，实际上应当尽可能避免使用。

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

MySQL 也支持 LOCK TABLES 和 UNLOCK TABLES 语句，这是在服务器层实现的，和存储引擎无关。它们有本身的用途，但并不能替代事务处理。若是应用须要用到事务，仍是应该选择事务型存储引擎。

常常能够发现，应用已经将表从 MyISAM 转换到 InnoDB ，但仍是显示地使用 LOCK TABLES 语句。这不但没有必要，还会严重影响性能，实际上 InnoDB 在行级锁工做得更好。

LOCK TABLES 和事务之间相互影响的话，状况会变得很是复杂，在某些 MySQL 版本中甚至会产生没法预料的结果。所以，除了事务中禁用 AUTOCOMMIT，也可使用 LOCK TALBES 外，其它任什么时候候都不要显式地执行 LOCK TALBES，无论使用的是什么存储引擎。

高性能MySQL: 第3版/(美)施瓦茨等著, 宁海元等译, 北京: 电子工业出版社, 2013.5, 第6-12页。

4、多版本并发控制

MySQL 的大多数事务型存储引擎实现的都不是简单的行级锁。基于提高并发性能的考虑，它们通常都同时实现了多版本并发控制（MVCC）。不只是 MySQL，包括 Oracle，PostgreSQL 等其它数据库系统也都实现了 MVCC，但各自的实现机制不尽相同，由于 MVCC 没有一个统一的实现标准。

能够认为 MVCC 是行级锁的一个变种，可是它在不少状况下避免了加锁操做，所以开销更低。虽然实现机制有所不一样，但大都实现了非阻塞的读操做，写操做也只锁定必要的行。

MVCC 的实现，是经过保存数据在某个时间点的快照来实现的。也就是说，无论须要执行多长时间，每一个事务看到的数据都是一致的。根据事务开始的时间不一样，每一个事务对同一张表，，同一时刻看到的数据多是不同的。若是以前没有这方面的概念，这句话听起来就有点迷惑。熟悉了之后会发现，这句话其实仍是很容易理解的。

前面说道不一样存储引擎的 MVCC 实现是不一样的，典型的有乐观（optimistic）并发控制和悲观（pessimistic）并发控制。下面咱们经过 InnoDB 的简化版行为来讲明 MVCC 是如何工做的。

InnoDB 的 MVCC，是经过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的建立时间，一个保存行的过时时间（或删除时间）。固然存储的并非实际的时间值，而是系统版本号（system version number）。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会做为事务的版本号，用来和查询到的每行记录的版本号进行比较。下面看一下 REPEATABLE READ 隔离级别下，MVCC 具体是如何操做的：

SELECT

InnoDB 会根据如下两个条件检索每行记录：

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

只有符合上述两个条件的记录，才能返回做为查询结果。

INSERT

InnoDB 为新插入的每一行保存当前系统版本号做为行版本号。

DELETE

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

UPDATE

InnoDB 为插入一行新记录，保存当前系统版本号做为行版本号，一样保存当前系统版本号到原来的行做为行删除标识。

保存这两个额外系统版本号，使大多数读操做均可以不用加锁。这样设计使得读数据操做很简单，性能很好，而且也能保证只会读取到符合标准的行。不足之处是每行记录都须要额外的存储空间，须要作更多的行检查工做，以及一些额外的维护工做。

MVCC 只在 REPEATABLE READ 和 READ COMMITTED 两个隔离级别下工做。其它两个隔离级别都和 MVCC 不兼容，由于 READ UNCOMMITTED 老是读取最新的数据行，而不是符合当前事务版本的数据行。而 SERIALIZATION 则会对全部读取的行都加锁。

高性能MySQL: 第3版/(美)施瓦茨等著, 宁海元等译, 北京: 电子工业出版社, 2013.5, 第12-13页。