高性能MySQL--innodb中事务的隔离级别与锁的关系

最近买了《高性能MySQL》这本书回来看，从中收益颇多！我来一吐为快！

我们都知道事务，那么在什么情况下我们需要使用事务呢？

银行应用是解释事务的一个经典例子。假设一个银行的数据库有两张表：支票（checking）和储蓄（savings）表。现在johnson要从支票账户中转移200块大洋到储蓄表中，那么至少需要三个步骤：

1. 检查支票账户余额是否高于200块大洋
2. 支票账户减少200块大洋
3. 储蓄账户中增加200块大洋

试想一下，如果上面步骤执行到第二步，突然因为什么原因而终止了，顾客支票账户中莫名其妙的减少了200块大洋。如果顾客恰好是一位情绪激动的大妈，那你就等着大妈带着平底锅和四级头去银行找你吧！

所以为了避免这种情况，就必须用到事务，上述三个步骤中有任何一个执行失败，就必须回滚所有的步骤，以免有大妈找上门。事务SQL如下所示：

1. START TRANSACTION;
2. SELECT balance FROM checking WHERE customer_id=123456;
3. UPDATE checking SET balance = balance - 200 WHERE customer_id=123456;
4. UPDATE savings SET balance = balance + 200 WHERE customer_id=123456;
5. COMMIT;

事务之所以可靠，当然离不开ACID特性：

• 原子性(atomicity)：整个事务中的操作要么全部成功，要么全部失败。
• 一致性(consistency)：数据库总是从一个一致性状态转换到另一个一致性状态。比如上面所说的，事务开始前和执行后，顾客johnson在银行的总账户余额是一样的。
• 隔离性(isolation)：通常来说，一个事务所做的修改在提交之前，其他事务是不可见的。也就是说事务间是相互隔离的。
• 持久性(durability)：事务在提交之后，对数据库数据所做的修改是永久性的。

细心的人可能会注意到。在讨论隔离性的时候，我用了“通常来说”，下面就让我们讨论下事务的隔离级别。

• 未提交读(READ UNCOMMITTED)：事务中的修改，即使没有提交，其他事务也可以读到，这就有可能造成了脏读。
• 提交读(READ COMMITTED)：大多数数据库系统默认实用的隔离级别就是这种，但mysql不是。READ COMMITTED就是在事务提交前，所做的修改对其他事务是不可见的。但READ COMMITTED可能会造成不可重复读。就是在一个事务中，同样的查询语句，可能会得到不一样的结果。其实就是在两次查询中间，另一个事务修改了查询结果的值。
• 可重复读(REPETABLE READ)：REPETABLE READ解决了脏读和不可重复读的问题，但理论上，REPETABLE READ无法解决幻读的问题。幻读就是指，一个事务在读取某一范围的值时，另一个事务恰好在该范围内插入了新纪录，那么当你再次读取该范围的值时，就会产生幻行。这与不可重复读有点像，只不过不可重复读时UPDATE，而幻读时INSERT。
• 可串行化(SERIALIZABLE)：SERIALIZABLE读取每一行数据都要加锁，强制事务串行执行，所以可能导致大量的超时和锁争用问题。

到这里，如果还不是太懂，你需要细细消化下前面的内容，这时可以打开mysql，将隔离级别设置为READ COMMITTED。然后试试它是不是解决了脏读，会不会出现不可重复读？再将隔离级别设置为REPETABLE READ。看看REPETABLE READ是不是解决了不可重复读，会不会出现幻读？

SET session transaction isolation level read committed;

如果你真的实验了，会发现mysql的REPETABLE READ隔离级别并不会出现幻读的现象。那你有没有想过mysql的事务是怎么实现的呢？

你肯定听说mysql的表锁和行锁，那你可能以为事务是基于行锁实现的。其实并没有那么简单，为了提高并发性能，mysql的大多是事务引擎都同时实现了多版本并发控制（MVCC）。它在很多情况下避免了加锁操作，所以开销更低。MVCC大都实现了非阻塞的读操作，写操作也只锁定必要的行。

那么InnoDB中的MVCC是如何工作的呢？其实是通过在每行数据后面增加两个列，一个是创建版本号，一个是删除版本号。里面存储的是系统版本号，你开启一个事务系统版本号就会递增。事务开始时刻的系统版本号就作为事务版本号，用来和查询的每行记录的版本号做比较。下面看下REPETABLE READ隔离界别下，MVCC具体是如何操作的。

• SELECT查询出的数据需要满足2个条件    1、创建版本号 <= 系统版本号  2、删除版本号为空或删除版本号>系统版本号
• INSERT　    为新插入的每一行保存当前事务版本号为行的创建版本号
• UPDATE　　为插入的一行新记录保存当前事务版本号为行的创建版本号，同时保存当前事务版本号为原来的行的删除版本号
• DELETE　　为删除的每一行保存当前事务版本号为行的删除版本号

保存这两个额外的系统版本号，可以使大多数读操作都不用加锁，这样性能就会更好。但需要额外的存储空间和一些额外的检查工作，这也相当于用空间换时间。

在某些情况下我们还是需要用的锁。InnoDB采用两段锁协议。在事务执行过程中随时都可以加锁，事务提交或回滚时同时释放所有锁。这些锁一般都是隐式锁定，InnoDB会根据需要自动加锁。当然，你也可以通过SQL语句自己加锁：

SELECT ..... LOCK IN SHARE MODE;     乐观锁
SELECT ..... FOR UPDATE;             悲观锁

个人建议，除非你明确知道自己在干什么，否则轻易不要显式加锁，只会事倍功半！！！

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有