《高性能MySQL》笔记 - 并发控制

1 读写锁

共享锁（shared lock）或读锁（read lock）是共享的，或者说是相互不阻塞的。多个客户在同一时刻可以同时读取同一个资源，而互不干扰。

排他锁（exclusive lock）和写锁（write lock）是排他的，也就是说一个写锁会阻塞其他的写锁和读锁，这是出于安全策略的考虑，只有这样才能确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源。

2 锁粒度

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

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

所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡。Mysql存储引擎提供了可以实现自己的锁策略和锁粒度。

2.1 表锁（table lock）

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

2.2 行级锁（row lock）

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

3 事务

事物就是一组原子性的SQL查询，或者说一个独立的工作单元。事务内的语句，要么全部执行成功，要么全部执行失败。事务的ACID概念：原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。

事物SQL demo：

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;

3.1 原子性（atomicity）

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

3.2 一致性（consistency）

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

3.3 隔离线（isolation）

通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。在前面的例子中，当执行完第三条语句、第四条语句还未开始时，此时有另外一个账户汇总程序开始运行，则其看到的支票账户的余额并没有减去200美元。

3.4 持久性（durability）

一旦事务提交，则其所做的修改就会永久保存到数据库中。持久化是个有点模糊的概念，不可能做到100%持久性保证的策略。

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

4 隔离级别

4.1 READ UNCOMMITED(未提交读)

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

4.2 READ COMMITED(提交读)

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

4.3 REPEATABLE READ(可重复读)

REPEATABLE READ 解决了脏读的问题。该级别保证了在同一事务中多次读取同样记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读（Phantom Read）的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行(Phantom Row)。InnoDB 和 XtraDB 存储引擎通过多版本并发控制解决了幻读的问题。

4.4 SERIALIZABLE(可串行化)

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

隔离级别	脏读可能性	不可重复读可能性	幻读可能性	加锁读
未提交读	Yes	Yes	Yes	No
提交读	No	Yes	Yes	No
可重复读	No	No	Yes	No
可串行化	No	No	No	Yes

5 脏读和幻读

脏读（dirty read）：两个事务，一个事务读取到了另一个事务未提交的数据，这便是脏读。
幻读（phantom read）：两个事务，事务A与事务B，事务A在自己执行的过程中，执行了两次相同查询，第一次查询事务B未提交，第二次查询事务B已提交，从而造成两次查询结果不一样，这个其实被称为不可重复读；如果事务B是一个会影响查询结果的insert操作，则好像新多出来的行像幻觉一样，因此被称为幻读。其他事务的提交会影响在同一个事务中的重复查询结果。

6 死锁

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

# 事务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目前处理死锁的方法是：将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。

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

7 事务日志

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

8 MySQL中的事务

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

8.1 自动提交（AUTOCOMMIT）

MySQL默认操作模式就是autocommit自动提交模式。这就表示除非显式地开始一个事务，否则每个查询都被当做一个单独的事务自动执行。我们可以通过设置autocommit的值改变是否是自动提交autocommit模式。

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

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

MySQL可以通过执行SET TRANSACTION ISOLATION LEVEL命令来设置隔离级别。新的隔离级别会在下一个事务开始的时候生效。可以在配置文件中设置整个数据库的隔离级别，也可以只改变当前回话的隔离级别，MySQL能够识别所有的4个ANSI隔离级别，InnoDB引擎也支持所有的隔离级别。

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITED;

9 多版本并发控制

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

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

InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。一个保存了行的创建时的系统版本号，一个保存行的过期（删除)时的系统版本号。每开始一个事务系统版本号都会递增，事务开始时刻的系统版本号会作为事务的版本号。

1. SELECT，InnoDB会根据以下两个条件检查每行记录：
   • InnoDB只查找版本早于当前事务版本的数据行（行的系统版本号小于或者等于事务的系统版本号），这样可以确保事务读取到的行，要么是在事务开始之前已经存在的，要么是事务自身插入或者修改过的（结合以下INSERT、UPDATE操作理解）。
   • 行的删除版本要么未定义，要么大于当前事务版本号。可以确保事务读取到的行，在事务开启之前未被删除（结合以下DELETE操作理解）。
2. INSERT，InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
3. DELETE，InnoDB为删除的每一行保存当前系统版本号作为行删除标识（第二个隐藏列的作用来了）。
4. UPDATE，InnoDB将更新后的列作为新的行插入数据库（并不是覆盖），并保存当前系统版本号作为该行的行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

10 悲观锁和乐观锁

乐观锁：用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加1。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。

悲观锁：与乐观锁相对应的就是悲观锁了。悲观锁就是在操作数据时，认为此操作会出现数据冲突，所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作，这点跟java中的synchronized很相似，所以悲观锁需要耗费较多的时间。另外与乐观锁相对应的，悲观锁是由数据库自己实现了的，要用的时候，我们直接调用数据库的相关语句就可以了。