本节中的设置是在solrconfig.xml中的<updateHandler>元素中配置的，可能会影响索引更新的性能。这些设置将影响如何在内部进行更新。<updateHandler>配置不影响RequestHandlers处理客户端的update请求的更高级的配置。
业务系统通过一个数据库连接发给MySQL，经过SQL接口、解析器、优化器、执行器，解析SQL语句，生成执行计划，接着由执行器负责执行该计划，调用InnoDB的接口去实际执行。
一个事务要更新一行，如果刚好有另外一个事务拥有这一行的行锁，它会被锁住。既然进入等待状态，那么等到这个事务自己获取到行锁要更新数据时，它读到的值又是什么呢？
事务隔离级别提到，如果是可重复读，事务T启动时会创建一个视图read-view。 之后事务T执行期间，即使有其他事务修改了数据，事务T看到的仍然跟在启动时看到的一样。也就是说，一个在可重复读隔离级别下执行的事务，好像不受外界影响。
一个事务执行过程中看到的数据，和该事务在启动时看到的数据一致。 所以未提交的变更对其它事务是不可见的。
乐观锁（ Optimistic Lock ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
今天我们来学习一下MySQL的事务隔离是如何实现的。如果你对事务以及事务隔离级别还不太了解的话，这里左转。
为了解决上述问题，数据库通过锁机制 解决并发访问的问题。根据锁定对象不同：分为行级锁和表级锁；根据并发事务锁定的关系上看：分为共享锁定和独占锁定，共享锁定会防止独占锁定但允许其他的共享锁定。而独占锁定既防止共享锁定也防止其他独占锁定。为了更改数据，数据库必须在进行更改的行上施加行独占锁定，insert、update、delete 和 select for update 语句都会隐式采用必要的行锁定。
有一些客户端连接框架会在连接成功后默认修改设置，这可能导致意外的长事务。因此，显示启动事务明显是比较安全的，但是对于一些需要频繁使用事务的业务，每次都需要调用 begin 然后再 commit。对于这种情况，可以使用 commit work and chain，当 autocommit = 1时，使用该语句可以在提交以后自动开启下一个新事务。
幻读 : 针对update和delete操作里面的where条件查找满足条件的记录，InnoDB引擎会返回的所有满足条件的数据。
MySQL是一个服务器／客户端架构的软件，对于同一个服务器来说，可以有若干个客户端与之连接，每个客户端与服务器连接上之后，就可以称之为一个会话（Session）。我们可以同时在不同的会话里输入各种语句，这些语句可以作为事务的一部分进行处理。不同的会话可以同时发送请求，也就是说服务器可能同时在处理多个事务，这样子就会导致不同的事务可能同时访问到相同的记录。我们前边说过事务有一个特性称之为隔离性，理论上在某个事务对某个数据进行访问时，其他事务应该进行排队，当该事务提交之后，其他事务才可以继续访问这个数据。但是这样子的话对性能影响太大，所以设计数据库的大叔提出了各种隔离级别，来最大限度的提升系统并发处理事务的能力，但是这也是以牺牲一定的隔离性来达到的。
并发 BUG 很难通过测试找到，因为这样的错误只有在特殊时序下才会触发。这样的时序问题可能非常少发生，通常很难重现 1。并发性也很难推理，特别是在大型应用中，你不一定知道哪些其他代码正在访问DB。只有一个用户访问数据时，应用开发就够麻烦了，多用户并发更困难，每个数据都可能被多个用户修改。
本文详细的介绍了什么是MVCC？为什么要有MVCC？以及MVCC的内部实现原理：包括Undo Log的版本链是如何组织的，RR、RC两个级别下一致性读是如何实现的等。通过案例、插图，以最通俗易懂的方式，让你彻底掌握MVCC的来龙去脉。
在 MySQL架构（二）SQL 更新语句是如何执行的？中说到了 redo log 和 binlog 日志文件，在事务执行过程中，会分两个阶段写入这两份日志文件中，这也是为了保证两份日志之间的一致性，即维护 mysql 的数据一致性。
事务的四大特性为原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)，本篇专门说说隔离性。
数据库事务指的是一组数据操作，事务内的操作要么就是全部成功，要么就是全部失败，什么都不做，其实不是没做，是可能做了一部分但是只要有一步失败，就要回滚所有操作，有点一不做二不休的意思。
乐观锁与悲观锁 http://www.cnblogs.com/qjjazry/p/6581568.html
乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。
在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。
数据库事务（Database Transaction），是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功、要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。事务是数据库运行中的逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。
A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题，通过下面的账户取款转账就可以看出来：
关于这个分布式服务的幂等性，这是在使用分布式服务的时候会经常遇到的问题，比如，重复提交的问题。而幂等性，就是为了解决问题存在的一个概念了。
乐观锁和悲观锁 Q 为什么需要锁(并发控制) A 在多用户环境中，在同一时间可能会有多个用户更新相同的记录，会产生冲突，这就是著名的并发问题 典型的冲突: -- 丢失更新:一个事务的更新覆盖了其它事务的更新结果，这就是所谓的更新丢失。例如:用户A把值从6改成2，用户B把值从2改为6，则用户A丢失了他的更新。 -- 脏读:当一个事务读取其它完成一半食物的记录时，就会发生脏读。例如:用户A、B看到的值都是6，用户B把值改成了2，用户A读到的值仍为6。 为了解决这些并发带来的问题，需要引入并发控制机制 并发控制
和其它版本控制系统一样，Git 能在特定的重要动作发生时触发自定义脚本。 有两组这样的钩子：客户端的和服务器端的。 客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。 你可以随心所欲地运用这些钩子。
MVCC 的全称是 Multi- Version (opens new window) Concurrency Control，也就是多版本并发控制，该机制是只有支持事务的 InnoDB 引擎下才存在的，用来实现提高数据库的并发性能，可以做到：读不加锁，读写不冲突。
AB两个接口更新同一个表的字段，但是以B接口下发数据为准，上游调用A接口的同时调用C接口，C接口再同时调用B接口，理论情况下更新时间是按着A先插入了tabel的字段，B再进行更新，最终数据是以B接口下发数据为准的，但由于A接口下发业务逻辑复杂，导致短时间A接口未提交事务时B接口被调用就进行了更新并提交事务导致A接口的事务提交覆盖了B操作，但更可怕的就是A还未提交事务，表中无数据可更新，B无法更新的情况如何更新数据？目前方案在B接口调用时放入缓存数据，在A接口被调用时缓存中有数据则更新缓存中的数据，没有则表明此时B还未被调用则不更新，常规的发生异常或者B后提交事务可以解决，但是A未提交事务时，B无法更新的情况如何处理？
TP和AP最重要的区别就是事物。事务是指对系统进行的一组操作，为了保证系统的完整性，事务需要具有ACID特性，具体指原子性（Atomic）一致性（Consistency）隔离性（Isolation）持
第 3 篇文章和你讲事务隔离级别的时候提到过，如果是可重复读隔离级别，事务 T 启动的时候会创建一个视图 read-view，之后事务 T 执行期间，即使有其他事务修改了数据，事务 T 看到的仍然跟在启动时看到的一样。也就是说，一个在可重复读隔离级别下执行的事务，好像与世无争，不受外界影响。
前面其实单独写过事务隔离级别和 MVCC 的文章，但是感觉仍然没法把知识串起来，今天正好借着这道面试题来巩固一下知识体系，虽然文章比较长，不过都是大伙熟悉的知识，帮助大家理清思路而已~
多用户对数据库的并发访问带来几个问题，如脏读（dirty read）、幻读（phantom read）、更新丢失（lost update）和不可重复读（nonrepeatable read）。
首先，InnoDB会判读缓冲池里是否存在 id = 1 这条数据，如果不存在则从磁盘中加载到缓冲池中，而且还会对这行数据加独占锁，防止多个sql同时修改这行数据。
如果是可重复读级别. 事务T启动的时候会创建一个视图read-view. 之后事务T之星期间, 即使有其他事务修改了数据, 事务T看到的仍然跟在启动时候看到的一样.
可以对现有的表使用SQL语句，也可以对相应的持久化类使用ObjectScript操作来修改InterSystems IRIS®数据平台数据库的内容。 不能修改定义为只读的持久类(表)。
MySQL可以恢复到半个月内任意一秒的状态. mysql> create table T(ID int primary key, c int);
在看到 Compare 和 Swap 后，我们就应该知道，CAS 里面至少包含了两个动作，分别是比较和交换，在现在的 CPU 中，为这两个动作专门提供了一个指令，就是CAH 指令，由 CPU 来保证这两个操作一定是原子的，也就是说比较和交换这两个操作只能是要么全部完成，要么全部没有完成
脏读：当一个事务读取到其他事务还未提交的数据，因为未提交的数据，不一定是最终有效的数据。所以我们称为读到脏数据了。也就是脏读。 不可重复读：一个事务A读取数据之后，另外一个事务B将此数据修改，此时事务A再次查询，发现数据不一样了。这就是不可重复读。也可以叫做幻读。 幻读：又叫"幻象读",是''不可重复读''的一种特殊场景：当事务1两次执行''SELECT ... WHERE''检索一定范围内数据的操作中间，事务2在这个表中创建了(如[[INSERT]])了一行新数据，这条新数据正好满足事务1的“WHERE”子句。 注：可能有点绕，一般情况下，“不可重复读”和“幻读”大致的意思相同。只不过不可重复度是在数据行上发生的，也就是发生了update操作，再去读取这条数据，出现不可重复读。而幻读是在数据表上发生的，也就是发生了insert与delete操作。再去读取这张表，出现数据条目或者行数（记录数）不一样。出现了幻觉一样。 **
一致性读视图是InnoDB在实现MVCC用到的视图，用于读提交（RC）和可重复度（RR）隔离级别的实现。
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。
可重复读是指：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。
如果你觉得文字太长，可以直接先看文末思维导图总结，小编已为你整理了作者的主要观点，供你回顾与快速阅读~
ACID原则是数据库事务正常执行的四个基本要素，分别指原子性、一致性、隔离性及持久性。
具有排它性（我锁住当前数据后，比人看不到此数据），悲观锁一般是由数据库机制来做到的。
还是先在粉板上记一下方便。如果掌柜没有粉板，每次记账都翻账本，效率是不是低死啦？ MySQL也有这个问题，若每次更新操作都写进磁盘，然后磁盘也要找到对应记录，然后再更新，整个过程IO成本、搜索成本都很高。 何解？采用类似酒掌柜粉板的思路。
MVCC (Multiversion Concurrency Control)，多版本并发控制。顾名思义，MVCC是通过数据行的多个版本管理实现数据库的并发控制。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。
我的网站上一直有好多人留言催更 MySQL 日志（undo log、redo log、binlog）的文章。
事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。事务具有ACID属性。
要么全做，要么全不做，一系列操作都是不可分割的，如果在执行操作的过程发生了错误，那么就把已经执行的操作恢复成没执行之前的样子。比如转账不能只有一方扣钱另一方不增加余额。
若想更改，可将启动参数transaction-isolation的值set成READ-COMMITTED。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
