MySQL事务与并发控制

1. 并发控制：

无论何时，只要有多个查询需要在同一时刻修改数据，都会产生并发控制的问题。本节讨论MySQL在两个层面的并发控制：服务器层（Server层）与 存储引擎层。

1.1 读写锁：

在处理并发读或者写时，可以通过实现一个由两种类型的锁组成的锁系统解决并发控制的问题。这两种类型的锁通常被称为 共享锁（shared lock） 和 排他锁（exclusive lock），也叫 读锁（read lock） 和 写锁（write lock）。

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

1.2 锁粒度：

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

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

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

而MySQL则提供了多种选择。每种MySQL存储引擎都可以实现自己的锁策略和锁粒度。在存储引擎的设计中，锁管理是个非常重要的决定。将锁粒度固定在某个级别，可以为某些特定的应用场景提供更好的性能，但同时却会失去对另外一些应用场景的良好支持。好在MySQL支持多个存储引擎的架构，所以不需要单一的通用解决方案。下面将介绍两种最重要的锁策略。

表锁（table lock）：

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

尽管存储引擎可以管理自己的锁，MySQL本身（Server层）还是会使用各种有效的表锁来实现不同的目的。 例如，服务器会为诸如 ALTER TABLE 之类的语句使用表锁，而忽略存储引擎的锁机制。

行级锁（row lock）：

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

---

2. 事务：

事务是一组原子性的SQL查询，或者说一个独立的工作单元。如果数据库引擎能够成功的对数据库应用该组查询的全部语句，那么就执行该组查询。如果其中有任何一条语句因为崩溃或者其他原因无法执行，那么所有的语句都不会执行。也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。

银行事务是解释事务必要性的一个经典例子。

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

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

（2）一致性（consistency）：
数据库总是从一个一致性的状态转换到另外一个一致性的状态。

（3）隔离性（isolation）：
“通常来说”，一个事务所做的修改在最终提交之前，对其他事务是不可见的。

（4）持久性（durability）：
一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。持久性是个模糊的概念，因为实际上持久性也分很多不同的级别。

就像锁粒度的升级会增加系统开销一样，这种事务处理过程中额外的安全性，也会需要数据库系统做更多的额外工作。一个实现了ACID的数据库，相比没有实现ACID的数据库，通常会需要更强的CPU处理能力、更大的内存和更多的磁盘空间。

2.1 隔离级别：

在SQL标准中定义了四种隔离级别，每一种级别都规定了一个事务中所做的修改，哪些在事务内和事务间是可见的，哪些是不可见的。较低级别的隔离通常可以执行更高的并发，系统的开销也更低。

MySQL中的四种隔离级别分别是：

（1）Read Uncommitted：（未提交读）
在Read Uncommitted级别，事务中的修改，即使没有提交，对其他事务也是可见的。事务可以读取未提交的数据，这也被称为 脏读（dirty read）。这个级别会导致很多问题，从性能上来说，Read Uncommitted不会比其他级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。

（2）Read Committed：（提交读）
大多数数据库系统的默认隔离级别都是Read Committed（但MySQL不是）。Read Committed满足前面提到的隔离性的简单定义：一个事务开始时，只能“看见”已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复度（nonrepeatable read），因为两次执行同样的查询，可能会得到不一样的结果。

（3）Repeatable Read：（可重复读）
Repeatable Read解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读（phantom read）的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的纪录，当之前的事务再次读取该范围的记录时，会产生幻行（phantom row）。InnoDB和XtraDb存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读的问题。
可重复读是MySQL的默认事务隔离级别。

（4）Serializable：（可串行化）
Serializable是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，Serializable会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。

2.2 死锁：

死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，就可能会产生死锁。多个事务同时锁定一个资源时，也会产生死锁。

例如：

//事务1：
START TRANSACTION;
UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4 and date = '2002-05-01';
UPDATE StockPrice SET close = 18.90 WHERE stocd_id = 3 and date = '2002-05-02';

//事务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 stocd_id = 4 and date = '2002-05-01';

为了解决这种问题，数据库实现了各种 死锁检测 和 死锁超时 机制。越复杂的系统，比如InnoDB引擎，越能检测死锁的循环依赖，并立即返回一个错误。这种检测方式很有效，否则死锁会导致出现非常慢的查询。还有一种方法，就是当查询的时间达到锁等待超时的设定后放弃锁请求，这种方式通常来说不太好。
InnoDB目前处理死锁的方法是（当未成功提前检测到死锁依赖，死锁已经发生时）：将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。

锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则是完全由于存储引擎的实现方式导致的。

死锁发生以后，只有部分或者完全回滚其中一个事务，才能打破死锁。 对于事务性的系统，这是无法避免的，所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需要重新执行因死锁回滚的事务即可。

2.3 事务日志：

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

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

2.4 MySQL中的事务：

MySQL提供了两种事务型的存储引擎：InnoDB 和 NDB Cluster。另外还有一些第三方存储引擎也支持事务，比较知名的包括 XtraDB 和 PBXT。
下面详细的讨论它们各自的一些特点：

自动提交：（AUTOCOMMIT）

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

mysql> SHOW VARIABLES LIKE 'AUTOCOMMIT';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.00 sec)
mysql> SET AUTOCOMMIT = 1;

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

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

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

如果在事务中混合使用了事务型和非事务型的表（比如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 语句，这是在服务器层实现的，和存储引擎无关。它们有自己的用途，但并不能替代事务处理。如果应用需要用到事务，还是应该选择事务型存储引擎。

---

3. 多版本并发控制：

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

可以认为MVCC是行级锁的一个变种， 但是在很多情况下避免了加锁操作，因此开销更低。虽然实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。

前面说到不同存储引擎的MVCC实现是不同的，典型的有 乐观并发控制（optimistic） 和 悲观并发控制（pessimistic） 。下面我们通过InnoDB的简化版行为来说明MVCC是如何工作的。

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

（1）SELECT：
InnoDB会根据以下两个条件检查每行记录：
a. InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
b. 行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。

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

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

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

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

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

MVCC 只在 Repeatable Read 和 Read Committed 两个隔离级别下工作。 其他两个隔离级别都和MVCC不兼容，因为 Read Uncommitted 总是读取最新的数据行，而不是符合当前事务版本的数据行。而 Serializable 则会对所有读取的行都加锁。

---

4. MySQL事务的具体实现语句：

4.1 事务控制语句：

// 标识事务的开始：
BEGIN; 或者 START TRANSACTION; //二者等价
// 提交：
COMMIT;
// 回退：
ROLLBACK;

// 设置回退点：
SAVEPOINT <point_name>;
ROLLBACK TO <point_name>;
RELEASE SAVEPOINT <point_name>;

举例：

//第一组：begin + commit, 成功提交
mysql> begin;  //开始事务
mysql> insert into runoob_tb1 
    -> (runoob_title, runoob_author, submission_date) 
    -> values
    -> ("学习", "计算机", NOW());
    //select * from runoob_tb1; 
    //这时查看表是可以查到新插入的这项的，但是并不是真正的插入，可以回退掉，
    //因为整个事务只能要么全完成，要么全不完成
mysql> insert into runoob_tb1 
    -> (runoob_title, runoob_author, submission_date) 
    -> values
    -> ("学习", "数据库", NOW());
mysql> commit; //提交事务

//第二组：begin + rollback, 回退不提交
mysql> begin; //开始事务
mysql> insert into runoob_tb1 
    -> (runoob_title, runoob_author, submission_date) 
    -> values
    -> ("学习", "数据库", NOW());
mysql> rollback; //回退，不提交

//第三组：begin + savepoint + rollback to + commit, 回退一部分后提交
mysql> start transaction;
mysql> insert into runoob_tb1
    -> (runoob_title, runoob_author, submission_date)
    -> values
    -> ("事务", "操作_1", NOW());
mysql> savepoint point_1; //回退点的名字随便起，留给后面rollback to使用
		//这里就是一个分界点，rollback to point_1; 后，
		//保留点前面的操作保留，保留点后面的操作删除
mysql> insert into runoob_tb1
    -> (runoob_title, runoob_author, submission_date)
    -> values
    -> ("事务", "操作_2", NOW());
mysql> rollback to point_1;
mysql> commit; //"操作_1"会提交成功

4.2 查看当前有哪些运行的事务：

//查看当前运行着的所有事务，及具体的语句：
select * from information_schema.INNODB_TRX;

//查看当前出现的锁：
select * from information_schema.INNODB_LOCKS;

//锁等待的对应关系：
select * from infomation_schema.INNODB_LOCKS_WAITS;

MySQL中有三个数据库是自带的：

mysql> show databases;

information_schema
mysql
performance_schema

其中，information_schema 和 performance_schema 一样，都是MySQL自带的“信息数据库”。performance_schema 用于 性能分析；information_schema 用于存储数据库元数据（关于数据的数据），例如数据库名、表名、列的数据类型、访问权限等。