原子性是指事务包含的所有 *** 作要么全部成功，要么全部失败回滚，因此事务的 *** 作如果成功就必须要完全应用到数据库，如果 *** 作失败则不能对数据库有任何影响。
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。举例来说，假设用户A和用户B两者的钱加起来一共是1000，那么不管A和B之间如何转账、转几次账，事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性。
隔离性是当多个用户并发访问数据库时，比如同时 *** 作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的 *** 作所干扰，多个并发事务之间要相互隔离。关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的 *** 作。例如我们在使用JDBC *** 作数据库时，在提交事务方法后，提示用户事务 *** 作完成，当我们程序执行完成直到看到提示后，就可以认定事务已经正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成。否则的话就会造成我们虽然看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。这是不允许的。
在数据库 *** 作中，在并发的情况下可能出现如下问题：
正是为了解决以上情况，数据库提供了几种隔离级别。
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted(未授权读取、读未提交)、Read committed（授权读取、读提交）、Repeatable read（可重复读取）、Serializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻象读这几类问题。
虽然数据库的隔离级别可以解决大多数问题，但是灵活度较差，为此又提出了悲观锁和乐观锁的概念。
悲观锁，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制。也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统的数据访问层中实现了加锁机制，也无法保证外部系统不会修改数据。
商品t_items表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单（此时该商品无法再次下单），那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。
如果不采用锁，那么 *** 作方法如下：
但是上面这种场景在高并发访问的情况下很可能会出现问题。例如当第一步 *** 作中，查询出来的商品status为1。但是当我们执行第三步Update *** 作的时候，有可能出现其他人先一步对商品下单把t_items中的status修改为2了，但是我们并不知道数据已经被修改了，这样就可能造成同一个商品被下单2次，使得数据不一致。所以说这种方式是不安全的。
在上面的场景中，商品信息从查询出来到修改，中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出t_items信息后就把当前的数据锁定，直到我们修改完毕后再解锁。那么在这个过程中，因为t_items被锁定了，就不会出现有第三者来对其进行修改了。需要注意的是，要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新 *** 作后，MySQL会立刻将结果进行提交。我们可以使用命令设置MySQL为非autocommit模式： set autocommit=0
设置完autocommit后，我们就可以执行我们的正常业务了。具体如下：
上面的begin/commit为事务的开始和结束，因为在前一步我们关闭了mysql的autocommit，所以需要手动控制事务的提交。
上面的第一步我们执行了一次查询 *** 作： select status from t_items where id=1 for update 与普通查询不一样的是，我们使用了 select…for update 的方式，这样就通过数据库实现了悲观锁。此时在t_items表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。需要注意的是，在事务中，只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE *** 作同一个数据时才会等待其它事务结束后才执行，一般 SELECT ... 则不受此影响。拿上面的实例来说，当我执行 select status from t_items where id=1 for update 后。我在另外的事务中如果再次执行 select status from t_items where id=1 for update 则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行 select status from t_items where id=1 则能正常查询出数据，不会受第一个事务的影响。
使用 select…for update 会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键或者索引，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。举例如下：
1、 select * from t_items where id=1 for update
这条语句明确指定主键（id=1），并且有此数据（id=1的数据存在），则采用row lock。只锁定当前这条数据。
2、 select * from t_items where id=3 for update
这条语句明确指定主键，但是却查无此数据，此时不会产生lock（没有元数据，又去lock谁呢？）。
3、 select * from t_items where name='手机' for update
这条语句没有指定数据的主键，那么此时产生table lock，即在当前事务提交前整张数据表的所有字段将无法被查询。
4、 select * from t_items where id>0 for update 或者 select * from t_items where id>1 for update （注：>在SQL中表示不等于）
上述两条语句的主键都不明确，也会产生table lock。
5、 select * from t_items where status=1 for update （假设为status字段添加了索引）
这条语句明确指定了索引，并且有此数据，则产生row lock。
6、 select * from t_items where status=3 for update （假设为status字段添加了索引）
这条语句明确指定索引，但是根据索引查无此数据，也就不会产生lock。
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以只会在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回用户错误的信息，让用户决定如何去做。实现乐观锁一般来说有以下2种方式：
以上不是重点，重点是 对事务控制语句不熟悉。
SAVEPOINT identifier : 在事务中 创建保存点。一个事务中 允许有多个保存点。
RELEASE SAVEPOINT identifier : 删除保存点。当事务中 没有指定的 保存点，执行该语句 会抛异常。
ROLLBACK TO identifier : 把事务回滚到 保存点。
Say you have a table T with a column C with one row in it, say it has the value '1'. And consider you have a simple task like following:
That is a simple task that issue two reads from table T, with a delay of 1 minute between them.
If you follow the logic above you can quickly realize that SERIALIZABLE transactions, while they may make life easy for you, are always completely blocking every possible concurrent operation, since they require that nobody can modify, delete nor insert any row. The default transaction isolation level of the .Net System.Transactions scope is serializable, and this usually explains the abysmal performance that results.
在Repeatable Read隔离级别下，一个事务可能会遇到幻读（Phantom Read）的问题。
幻读是指，在一个事务中，第一次查询某条记录，发现没有，但是，当试图更新这条不存在的记录时，竟然能成功，并且，再次读取同一条记录，它就神奇地出现了。
我们仍然先准备好students表的数据：
然后，分别开启两个MySQL客户端连接，按顺序依次执行事务A和事务B：
事务B在第3步第一次读取id=99的记录时，读到的记录为空，说明不存在id=99的记录。随后，事务A在第4步插入了一条id=99的记录并提交。事务B在第6步再次读取id=99的记录时，读到的记录仍然为空，但是，事务B在第7步试图更新这条不存在的记录时，竟然成功了，并且，事务B在第8步再次读取id=99的记录时，记录出现了。
可见，幻读就是没有读到的记录，以为不存在，但其实是可以更新成功的，并且，更新成功后，再次读取，就出现了。
在冲突较少的情况下，使用乐观锁。乐观锁 因为没有 加锁 释放锁，也减少了 加锁 释放锁的开销。
冲突较多时，如果使用乐观锁 需要不停地尝试，所以 使用悲观锁。
如果乐观锁 进行尝试时 的花销较大，也是使用悲观锁。
术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。
隔离级别的产生
在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。
事务的4种隔离级别
READ UNCOMMITTED 未提交读，可以读取未提交的数据。READ COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE 序列化
在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身&间隙)，以及了解整个数据范围的全集组成。
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；
SQL 语句根据条件扫描到的可能需要加锁的数据范围；
以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）
1. 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）
整形，对值具有唯一约束条件的数据范围 1～5 ，
已有数据1、2、3、4、5，此时数据范围已被完全填充；
整形，对值具有唯一约束条件的数据范围 1 和 5 ，
已有数据1、5，此时数据范围已被完全填充；
2. 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）
整形的数据范围 1～5 ，
已有数据 1、2、3、4、5，但是因为没有唯一约束，
所以数据范围可以继续被 1～5 的数据重复填充；
整形，具有唯一约束条件的数据范围 1～5 ，
已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；
3. 数据范围内没有任何数据（存在间隙）
如下：
整形的数据范围 1～5 ，数据范围内当前没有任何数据。
在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。
无控制的并发所带来的问题
并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。
1. 范围内已有数据更改导致的：
更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，
由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；
脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。
这时，另外一个事务也来读取同一条记录，如果不加控制，
第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。
这种现象就叫“脏读”。
2. 范围内数据量发生了变化导致：
不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，
却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。
这种现象就叫“不可重复读”。
幻读：一个事务按相同的查询条件重新读取以前检索过的数据，
却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。
可以简单的认为满足条件的数据量变化了。
因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。
MySQL 隔离级别的实现
InnoDB 通过加锁的策略来支持这些隔离级别。
行锁包含：
Record Locks
索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，
这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。
Gap Locks
间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。
间隙锁是性能和并发之间权衡的一部分。
对于无间隙的数据范围不需要间隙锁，因为没有间隙。
Next-Key Locks
索引记录上的记录锁和索引记录之前的 gap lock 的组合。
假设索引包含 10、11、13 和 20。
可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：
(负无穷大, 10] (10, 11] (11, 13] (13, 20] (20, 正无穷大) 对于最后一个间隔，next-key将会锁定索引中最大值的上方，
左右滑动进行查看
"上确界"伪记录的值高于索引中任何实际值。
上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。
基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。
对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。
默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。
READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。
对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，
以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。
总结&延展：
唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。
当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。
行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。
例如，
在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。
session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。
session A 通过索引 idA，session B通过索引 idB 。
当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。
比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。
间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。
rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。
rr 模式下，为了防止幻读，会加上 Gap Locks。
事务中，SQL 开始则加锁，事务结束才释放锁。
就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。
就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。
锁只是并发控制的一种粒度，只是一个很小的部分：
从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)
并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)
相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)
粒度加载的安全&性能(如获取行锁前，先获取页锁，页锁在执行获取行锁 *** 作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）