事务的定义
事务由单独单元的一个或多个SQL语句组成，在这个单元中，每个MySQL语句是相互依赖的。而整个单独单元作为一个不可分割的整体，如果单元中某条SQL语句一旦执行失败或产生错误，整个单元将会回滚。所有受到影响的数据将返回到事务开始以前的状态；如果单元中的所有SQL语句均执行成功，则事务被顺利执行。
事务的特性
事务有四个特性：ACID Atomicity（原子性）、Consistency（稳定性）、Isolation（隔离性）、Durability（可靠性）
1.原子性：一组事务，要么成功；要么撤回。
2.稳定性：有非法数据（外键约束之类），事务撤回。
3.隔离性：事务独立运行。一个事务处理后的结果，影响了其他事务，那么其他事务会撤回。事务的100%隔离，需要牺牲速度。
4.可靠性：软、硬件崩溃后，InnoDB数据表驱动会利用日志文件重构修改。
可靠性和高速度不可兼得， innodb_flush_log_at_trx_commit选项 决定什么时候把事务保存到日志里。
存储引擎
MySQL的事务支持不是绑定在MySQL服务器本身，而是与存储引擎相关
1.存储引擎的概念：在mysql中的数据用各种不同的技术存储在文件（或内存）中。
这些技术中的每一种技术都使用不同的存储机制，索引 技巧，并且最终提供广泛的不同的功能和能力。可以通过选择不同的技术，可以获得额外的速度或功能，从而改善应用的整体功能。
2.这些不同的技术以及配套的相关功能在mysql中被称为存储引擎（也称为表类型）。
3.通过show engines；来查看mysql支持的存储引擎。
4. 在mysql中用的最多的存储引擎有：innodb，bdb，myisam ,memory 等。其中innodb和bdb支持事务而myisam等不支持事务。
事务的隔离
事务隔离级别：
1.Read Uncommitted（读取未提交内容）
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
2.Read Committed（读取提交内容）
这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
3.Repeatable Read（可重读）
这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：
<幻读（Phantom Read）。幻读的解释有很多种，其中一种幻读的解释指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题；还有一种解释将幻读与不可重复读归为一类。还有一个解释为： 是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。
4.Serializable（可串行化）
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。
简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。
事务隔离模式查看和设置
查看：select @@tx_isolation;
设置：
1、SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE
1、不带SESSION、GLOBAL的SET命令
只对下一个事务有效
2、SET SESSION
为当前会话设置隔离模式
3、SET GLOBAL
为以后新建的所有MYSQL连接设置隔离模式（当前连接不包括在内）
2、set [session.|global.]tx_isolation='READ-UNCOMMITTED' | 'READ-COMMITTED' | 'REPEATABLE-READ' | 'SERIALIZABLE'
MYSQL的事务处理方法
1.用begin/start transaction,rollback,commit来实现，begin或者start transaction开始一个事务，rollback事务回滚，commit事务确认
2.直接用set来改变mysql的自动提交模式，mysql默认是自动提交的，也就是你提交一个query，就直接执行！
可以通过set autocommit = 0 禁止自动提交set autocommit = 1 开启自动提交来实现事务的处理。
要注意当用set autocommit = 0 的时候，你以后所有的sql都将作为事务处理，直到你用commit确认或 rollback结束，注意当你结束这个事务的同时也开启了新的事务！按第一种方法只将当前的做为一个事务!
四种隔离级别的测试
打开两个mysql的连接，进入到对应的数据库test中，测试的表为example，字段为id(int),name(char),status(int);
Read Uncommitted
| 测试步骤 | conn1 | conn2 | 结果 |
|---|---|---|---|
| 1 | begin; | begin; | |
| 2 | select * from example; | 空 | |
| 3 | select * from example; | 空 | |
| 4 | insert into example (name,status) value ('a',1); | ||
| 5 | select * from example; | 有数据 | |
| 6 | select * from example; | 有数据（脏读） | |
| 7 | rollback; | ||
| 8 | select * from example; | 没有数据 | |
| 9 | select * from example; | 没有数据 |
Read committed
| 测试步骤 | conn1 | conn2 | 结果 |
|---|---|---|---|
| 1 | begin; | begin; | |
| 2 | select * from example; | 空 | |
| 3 | select * from example; | 空 | |
| 4 | insert into example (name,status) value ('a',1); | ||
| 5 | select * from example; | 有数据 | |
| 6 | select * from example; | 没有数据 | |
| 7 | commit; | ||
| 8 | select * from example; | 有数据 | |
| 9 | select * from example; | 有数据 |
Repeatable read
| 测试步骤 | conn1 | conn2 | 结果 |
|---|---|---|---|
| 1 | begin; | begin; | |
| 2 | select * from example; | 有1条数据 | |
| 3 | select * from example; | 有1条数据 | |
| 4 | insert into example (name,status) value ('b',1); | ||
| 5 | select * from example; | 有2条数据 | |
| 6 | select * from example; | 有1条数据 | |
| 7 | commit; | ||
| 8 | select * from example; | 有1条数据 | |
| 9 | commit; | ||
| 10 | select * from example; | 有2条数据 |
Serializable
例1：
| 测试步骤 | conn1 | conn2 | 结果 |
|---|---|---|---|
| 1 | begin; | begin; | |
| 2 | select * from example; | 有2条数据 | |
| 3 | select * from example; | 有2条数据 | |
| 4 | insert into example (name,status) value ('c',1); | 一直等待中 | |
| 5 | commit; | ||
| 6 | conn1中执行成功 | ||
| 7 | commit; | ||
| 8 | select * from example; | 有3条数据 | |
| 9 | select * from example; | 有3条数据 |
例2：
| 测试步骤 | conn1 | conn2 | 结果 |
|---|---|---|---|
| 1 | begin; | begin; | |
| 2 | select * from example; | 有3条数据 | |
| 4 | insert into example (name,status) value ('d',1); | ||
| 3 | select * from example; | 一直等待中 | |
| 5 | commit; | ||
| 6 | conn2中查询成功 | ||
| 7 | commit; | ||
| 8 | select * from example; | 有4条数据 | |
| 9 | select * from example; | 有4条数据 |
数据库封锁技术
为了体现隔离级别，数据库使用了封锁技术（locking）
(1)S锁，Share Locks，共享锁，读锁，被加锁的对象可以被持锁事务读取，但是不能被修改，其他事务也可以在上面再加s锁。(2)X锁，Exclusive Locks，排他锁，写锁，被加锁的对象只能被持有锁的事务读取和修改，其他事务无法在该对象上加其他锁，也不能读取和修改该对象。
引入封锁技术又带来了“死锁”问题
解决死锁的两类方法：(1)预防法：一次封锁法（每个事务必须将所用到的数据全部加锁，否则不能执行）和顺序封锁法（对用到的数据按照预先设定的顺序加锁）。(2)诊断解除法：超时法（一事务超过规定时间则判定发生死锁）和等待图法（事务等待图是一个有向图G=(T,U)，T为结点的集合，每个结点表示正在运行的事务；U为边的集合，每条边表示事务等待的情况。若事务T1等待事务T2，则T1，T2之间有一条有向边，从 T1 指向 T2。如果发现图中存在回路，则表示系统中出现了死锁）。
封锁协议（Locking Protocol）
保证数据一致性的封锁协议的三级封锁协议
对并发操作的不正确调度可能会带来的三种数据不一致性：丢失修改、不可重复读和读“脏”数据。三级封锁协议分别在不同程度上解决了这一问题。(1)1级封锁协议:事务T修改数据R之前必须先对其X加锁，直到事务结束才释放。事务结束包括正常结束和非正常结束。1级封锁协议可防止丢失修改，并保证事务T是可恢复的。在1级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不读“脏”数据。(2)2级封锁协议:1级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。2级封锁协议除防止丢失修改，还可进一步防止读“脏”数据。在2级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证保重复读。(3)3级封锁协议:1级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结果才释放。3级封锁协议除防止丢失修改和不读“脏”数据外，还进一步防止了不可重复读。
保证并行调度可串行性的封锁协议的两段锁协议
可串行性是并行调度正确性的唯一准则，两段锁（简称2PL）协议是为保证并行调度可串行性而提供的封锁协议。两段锁协议规定：在对任何数据进行读、写操作之前，事务道首先要获得对该数据的封锁，而且在释放一个封锁之生，事务不再获得任何其他封锁。所谓“两段”锁的含义是，事务分为两个阶段，第一阶段是获得封锁，也称为扩展阶段，第二阶段是释放封锁，也称为收缩阶段。
可串行化
调度是一个或多个事务的重要操作按时间排序的一个序列。如果一个调度的动作首先是一个事务的所有动作，然后是另一个事务的所有动作，以此类推，而没有动作的混合，那么我们说这一调度是串行的。事务的正确性原则告诉我们，每个串行调度都将保持数据库状态的一致性。 通常，不管数据库初态怎样，一个调度对数据库状态的影响都和某个串行调度相同，我们就说这个调度是可串行化的。[如果一并行调度的结果等价于某一串行调度的结果，那么这个并行调度成为可串行化的]
在并发控制中采用封锁协议解决数据的不一致性并发控制的主要方法是封锁(Locking)。就是要用正确的方式调度并发操作，使一个用户的事务在执行过程中不受其他事务的干扰，从而避免造成数据的不一致性。封锁是使事务对它要操作的数据有一定的控制能力。封锁通常具有3 个环节:第一个环节是申请加锁，即事务在操作前要对它将使用的数据提出加锁申请; 第二个环节是获得锁，即当条件成熟时，系统允许事务对数据进行加锁，从而事务获得数据的控制权；第三个环节是释放锁，即完成操作后事务放弃数据的控制权。
封锁是实现并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该 数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。 基本的封锁类型有两种：排它锁（Exclusive locks 简记为X锁）和共享锁（Share locks 简记为S锁）。
排它锁又称为写锁。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其它事务在T释放A上的锁之前不能再读取和修改A。 共享锁又称为读锁。若事务T对数据对象A加上S锁，则其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其它事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
在运用X锁和S锁这两种基本封锁，对数据对象加锁时，还需要约定一些规则，例如应何时申请X锁或S锁、持锁时间、何时释放等。我们称这些规则为封锁协议 （Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。下面介绍三级封锁协议。三级封锁协议分别在不同程度上解决了丢失的修改、不 可重复读和读"脏"数据等不一致性问题，为并发操作的正确调度提供一定的保证。下面只给出三级封锁协议的定义，不再做过多探讨。
1级封锁协议是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。1级封锁协议可防止丢失修改，并保证事务T是可恢复的。在1级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不 读"脏"数据。
2级封锁协议是：1级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。2级封锁协议除防止了丢失修改，还可进一步防止读"脏"数据。
3级封锁协议是：1级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。3级封锁协议除防止了丢失修改和不读'脏'数据外，还进一步防止了不可重复读。执行了封锁协议之后，就可以克服数据库操作中的数据不一致所引起的问题。
事务锁定模式
系统默认： 不需要等待某事务结束，可直接查询到结果，但不能再进行修改、删除。
缺点：查询到的结果，可能是已经过期的。
优点：不需要等待某事务结束，可直接查询到结果。
需要用以下模式来设定锁定模式
1、SELECT …… LOCK IN SHARE MODE（共享锁）
查询到的数据，就是数据库在这一时刻的数据（其他已commit事务的结果，已经反应到这里了）
SELECT 必须等待，某个事务结束后才能执行
2、SELECT …… FOR UPDATE（排它锁）
例如 SELECT * FROM tablename WHERE id<200
那么id<200的数据，被查询到的数据，都将不能再进行修改、删除、SELECT …… LOCK IN SHARE MODE操作
一直到此事务结束
共享锁 和 排它锁 的区别：在于是否阻断其他客户发出的 SELECT …… LOCK IN SHARE MODE命令
3、INSERT / UPDATE / DELETE
所有关联数据都会被锁定，加上排它锁
4、防插入锁
例如 SELECT * FROM tablename WHERE id>200
那么id>200的记录无法被插入
5、死锁
自动识别死锁
先进来的进程被执行，后来的进程收到出错消息，并按ROLLBACK方式回滚
innodb_lock_wait_timeout = n 来设置最长等待时间，默认是50秒
MySQL中一致性非锁定读
一致性非锁定读(consistent nonlocking read)是指InnoDB存储引擎通过多版本控制(multi versionning)的方式来读取当前执行时间数据库中行的数据，如果读取的行正在执行DELETE或UPDATE操作，这是读取操作不会因此等待行上锁的释放。相反的，InnoDB会去读取行的一个快照数据。
快照数据是指该行之前版本的数据，该实现是通过undo段来完成。而undo用来事务中的回滚数据，因此快照数据本身没有额外的开销，此外，读取快照数据不需要上锁，因为没有事务需要对历史数据进行修改操作
可以看到，非锁定读机制极大地提高了数据库的并发性，在InnoDB存储引擎的默认设置下，这是默认的读写方式，即读不会占用和等待表上的锁。但是在不同的事务隔离级别下，读取的方式不同，并不是每个事务隔离级别下都是采用非锁定的一致性读，此外，即使使用非锁定的一致性读，但是对于快照数据的定义也各不相同
快照其实是当前行数据之前的历史版本，每行记录可能有多个版本，如图显示，一个行记录可能有不止一个快照数据，一般称这种技术为多版本技术，因此带来的并发控制。称为多版本并发控制(Multi Version Concurrency Control,MVCC)
在事务隔离级别RC和RR下，InnoDB存储引擎引擎使用非锁定的一致性读。然而，对于快照数据的定义却不相同。在rc事务隔离级别下，对于快照数据，非一致性读总是被锁定行的最新一份快照数据.而在RR事务隔离级别下，对于快照数据，非一致性读总是读取事务开始时的行数据版本。
在可重读事务级别中
如果使用普通的读，会得到一致性的结果，如果使用了加锁的读，就会读到“最新的”“提交”读的结果。
本身，可重复读和提交读是矛盾的。在同一个事务里，如果保证了可重复读，就会看不到其他事务的提交，违背了提交读；如果保证了提交读，就会导致前后两次读到的结果不一致，违背了可重复读。
可以这么讲，InnoDB提供了这样的机制，在默认的可重复读的隔离级别里，可以使用加锁读去查询最新的数据。
SELECT * FROM t_bitfly LOCK IN SHARE MODE;
或者SELECT * FROM child WHERE id > 100 FOR UPDATE，这样，InnoDB会给id大于100的行（假如child表里有一行id为102），以及100-102，102+的gap都加上锁。
需要注意，使用加锁读后，表被锁住的部分在加锁读的事务结束前将无法更新
持续读意味着InnoDB使用它的多版本化来给一个查询展示某个时间点处数据库的快照。查询看到在那个时间点之前被提交的那些确切事务做的更改，并且没有其后的事务或未提交事务做的改变。这个规则的例外是，查询看到发布该查询的事务本身所做的改变。
如果你运行在默认的REPEATABLE READ隔离级别，则在同一事务内的所有持续读读取由该事务中第一个这样的读所确立的快照。你可以通过提交当前事务并在发布新查询的事务之后，为你的查询获得一个更新鲜的快照。
持续读是默认模式，在其中InnoDBzai在READ COMMITTED和REPEATABLE READ隔离级别处理SELECT语句。持续读不在任何它访问的表上设置锁定，因此，其它用户可自由地在持续读在一个表上执行的同一时间修改这些表。
注意，持续读不在DROP TABLE和ALTER TABLE上作用。持续读不在DROP TABLE上作用，因为MySQL不能使用已经被移除的表，并且InnoDB 破坏了该表。持续读不在ALTER TABLE上作用，因为它在某事务内执行，该事务创建一个新表，并且从旧表往新表中插入行。现在，当你重新发出持续读之时，它不能在新表中看见任何行，因为它们被插入到一个在持续读读取的快照中不可见的事务 里。
/* ==================== MySQL InnoDB 锁表与锁行 ======================== */
由于InnoDB预设是Row-Level Lock，所以只有「明确」的指定主键，MySQL才会执行Row lock (只锁住被选取的资料例) ，否则MySQL将会执行Table Lock (将整个资料表单给锁住)。
举个例子: 假设有个表单products ，里面有id跟name二个栏位，id是主键。
例1: (明确指定主键，并且有此笔资料，row lock)
复制代码代码如下:
SELECT * FROM products WHERE id='3' FOR UPDATE;SELECT * FROM products WHERE id='3' and type=1 FOR UPDATE;
例2: (明确指定主键，若查无此笔资料，无lock)
复制代码代码如下:
SELECT * FROM products WHERE id='-1' FOR UPDATE;
例3: (无主键，table lock)
复制代码代码如下:
SELECT * FROM products WHERE name='Mouse' FOR UPDATE;
例4: (主键不明确，table lock)
复制代码代码如下:
SELECT * FROM products WHERE id<>'3' FOR UPDATE;
例5: (主键不明确，table lock)
复制代码代码如下:
SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;
注1: FOR UPDATE仅适用于InnoDB，且必须在交易区块(BEGIN/COMMIT)中才能生效。注2: 要测试锁定的状况，可以利用MySQL的Command Mode ，开二个视窗来做测试。
在MySql 5.0中测试确实是这样的
另外：MyAsim 只支持表级锁，InnerDB支持行级锁添加了(行级锁/表级锁)锁的数据不能被其它事务再锁定，也不被其它事务修改（修改、删除）是表级锁时，不管是否查询到记录，都会锁定表此外，如果A与B都对表id进行查询但查询不到记录，则A与B在查询上不会进行row锁，但A与B都会获取排它锁，此时A再插入一条记录的话则会因为B已经有锁而处于等待中，此时B再插入一条同样的数据则会抛出Deadlock found when trying to get lock; try restarting transaction然后释放锁，此时A就获得了锁而插入成功
乐观锁与悲观锁
悲观锁
在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度(悲观)，因此，在整个数据处理过程中，将数据处于锁定状态。 悲观锁的实现，往往依靠数据库提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）
在数据库中，悲观锁的流程如下：
在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。
优点与不足
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数
乐观锁
在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。乐观事务控制最早是由孔祥重（H.T.Kung）教授提出。
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。
数据版本,为数据增加的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据。
实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。
优点与不足
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。
乐观锁失效
乐观锁存在失效的情况，属小概率事件，需要多个条件共同配合才会出现。如：
应用采用自己的策略管理主键ID。如，常见的取当前ID字段的最大值＋1作为新ID。
版本号字段 ver
默认值为 0 。
用户A读取了某个记录准备修改它。该记录正好是ID最大的记录，且之前没被修改过， ver 为默认值 0。
在用户A读取完成后，用户B恰好删除了该记录。之后，用户C又插入了一个新记录。
此时，阴差阳错的，新插入的记录的ID与用户A读取的记录的ID是一致的， 而版本号两者又都是默认值 0。
用户A在用户C操作完成后，修改完成记录并保存。由于ID、ver均可以匹配上， 因此用户A成功保存。但是，却把用户C插入的记录覆盖掉了。
乐观锁此时的失效，根本原因在于应用所使用的主键ID管理策略， 正好与乐观锁存在极小程度上的不兼容。
两者分开来看，都是没问题的。组合到一起之后，大致看去好像也没问题。 但是bug之所以成为bug，坑之所以能够坑死人，正是由于其隐蔽性。
对此，也有一些意见提出来，使用时间戳作为版本号字段，就可以避免这个问题。 但是，时间戳的话，如果精度不够，如毫秒级别，那么在高并发，或者非常凑巧情况下， 仍有失效的可能。而如果使用高精度时间戳的话，成本又太高。
使用时间戳，可靠性并不比使用整型好。问题还是要回到使用严谨的主键成生策略上来。
网友评论