一、事务

事务性数据库实现的是

支持未完成的数据修改回滚的机制，对应原子性力所能及的数据合法性检查，对应一致性保证数据并发的修改的规则，对应隔离性使用基于持久化存储（磁盘、SSD）的方式对数据进行存储，对应持久性

1. ACID的概念（原子性、一致性、隔离性、持久性）：

1.1Atomicity 原子性

很令人郁闷的是，这个词表达意思与常规语境下不太一样。对于一门支持并发的编程语言（比如Java，C++），原子性是指一组指令被执行时，不受其他指令的干扰。比如我们可以说CAS是原子的；给一个整型变量赋值是原子的等等。但是在ACID语境下，不受干扰这层意思其实是后边隔离性说的事情。在ACID语境下，原子性是指一组对数据库的改变，要么最终成功执行完成，要不就全部回滚。这就要求数据库系统要实现某种回滚的机制，比如redo/undo log）。所以，也许这里用术语revertability可能更适合。与事务性数据库相比，一些NoSQL的数据库也声称支持原子性，但是意义不同。比如Redis事务的原子性的意思可能更接近于一组指令被执行时，不受其他指令的干扰，而不是可以回滚。

1.2Consistency 一致性

这个术语的用词也颇为怪异。一般来讲，我们习惯用一致性来描述数据在某些条件下可以变成一样的。例如，在描述CPU工作方式时可以说需要主内存在CPU Core1里的缓存和CPU Core2里的缓存是一致的；或者，一个分布式数据系统中，A节点从B节点复制数据，A的数据要和B的数据"严格一致"或者最终一致。而ACID下的一致性指的是，在事务完成前后，数据都是要在业务意义上是正确的，所以也许术语correctness更适合这里的意思。但如果这样定义的话，数据库的位置就很尴尬了，因为保证业务是否正确是要业务代码来最终保证的，数据库能做的非常有限。目前数据库里实现的约束检查，比如唯一约束、外键约束、一些enum测检查、一些数据类型/长度/有效数字的检查等等，对于简单的场景还可以使用。对于复杂的业务约束检查，很难或者不可能实现。有一类数据正确性问题正是由于下面隔离性的使用不当而带来的。 真实复杂业务的数据正确性维护一般用正确的业务代码 + 合法性job来定时执行 + 数据库自身的简单合法性防护一起实现

1.3Isolation 隔离性

是指一组对数据库的并发修改互相不影响。这个概念表面上看来并不是能说得通，因为如果并发修改的是互不相干的数据，那么自然隔离性可以得到满足；如果并发修改的是相关联的，或者就是同一份数据，就必然会相互影响。那么，此时可以做的就是区分哪个修改优先级更加高。而高优先级的修改应该覆盖掉低优先级的修改。但是，现实往往更复杂，因为并发的修改并不一定能够讲明白先来后到的（要不怎么叫并发呢），此时谁应该生效无法很好的定义。另外一种情况是先读取，再基于读取结果对数据进行修改这样业务逻辑。比如，先找到可用的库存，有则扣减，没有则提示缺货；再比如先读取当前的计数值，再往上加1。这时保证隔离性的主要问题不在于隔离本身，而在于如果将读取作为对数据修改的前提条件，之后在对数据进行修改的一刹那，读取时的前提条件还是否满足。毕竟读取和写入是两个分开的指令，而在这两个指令中间可能夹杂其他事务对数据的修改。保持隔离性的一个简单做法是保证对关联数据的修改串行化，对应事务性数据库的Serializable隔离级别。保证串行化的一种方案是锁，通过锁定可以彻底避免竞争条件。但是大家都能明白加锁对数据库并发的性能负面影响很大，所以就衍生出了几种弱一些的隔离性保证——READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ。此外MVCC能够解决一部分锁带来的问题。这些内容在下文中会详细的讲解。

1.4.Duration 持久性

是指对数据的修改，一旦完成，该结果就应当永远不丢失。这是这4个术语中我唯一觉得表面上和实际上意思差不多的一条。在现实当中，一般通过持久性存储设备（比如磁盘/SSD）写入并刷新来保证数据的持久性。如果觉得一个节点不靠谱，可以增加多个副本（replica）一起来保证持久；如果觉得这样还不够靠谱，可以在不同的地理位置的另一个数据中心做备份。实际上绝对的持久性是不存在的，因为整个存储层面有很多不确定因素，比如文件系统本身fsync指令实现有bug，磁盘的固件有bug，供电出现问题造成数据错乱，异步的数据复制没有生效等等。所以在现实当中的数据库，只能在当前成本和技术限制的约束下，尽量维持一定程度的持久性。

二、隔离级别和并发控制

四种隔离级别

Read UncommittedRead CommittedRepeatable ReadSerializable

定义这4种隔离级别时，制定者主要围绕着基于锁的并发控制来说的。但是后来出现了MVCC，之后主流数据库都开始支持MVCC。有的数据库采用比较纯粹的MVCC实现，比如PostgreSQL；有的则是混杂的，比如MySQL InnoDB。这就会造成数据库的实现和标准的描述有很多出入。

1. 最不严格的隔离级别

理论上，最不严格的隔离级别应该是不隔离。

不隔离很容易理解，不同的事务可以对同一数据并发的随便改：A事务改了一半的结果B能看到；B改了一半的结果A也能看到；如果A和B反复修改同一个数据，那么彼此的修改可以覆盖。数据系统在没有做隔离防护时，就一定会是这个样子。这样也就无所谓事务了。

这里数据访问冲突可以分为两种：

Dirty Read，脏读。即一个事务的没提交之前的修改被另外一个事务可以看到。Dirty Write，脏写。即一个事务的没提交之前的修改可以被另外一个事务的修改覆盖掉。

其实脏读在某些场景下还是可以接受的，比如完全不需要读取-计算-修改逻辑的事务。这种事务完全不在意别的事物是怎么修改的，就是自己改自己的；要不就是业务上就算是基于一个错误的前提进行了数据修改，结果也可以接受的场景。

而脏写是无法被接受的，因为他会让事务原子性无法实现。试想以下A和B两个事务的行为（假设x的值一开始是0）：

事务B将事务A的修改覆盖了，将x改为2，然后回滚。但是事务A却commit了。此时x应该是多少呢？从事务A的角度可能应该是1，但是从事务B的角度应该是0。这种情况无论如何都不能自洽。因此，任何支持事务的数据库都有一个基本原则：不论隔离级别是什么，脏写都是不允许的！！如何避免脏写呢？答案很简单——使用锁。实际上，一般数据库都会使用排他锁来标记要修改的数据（update，delete，select … for update)。锁的存在可以保证——写要block写。这个规则永远生效。在MySQL InnoDB中，这种锁被称为X锁。它的特性是，只要有一个事务获取了一条数据的X锁，其他事物如果也想获取这个锁，就必须等待，直到第一个事务提交/回滚后释放锁，或者等到超时自动回滚。例如上面的案列的第二行事务B尝试进行set x = 2就会被排他锁卡住。有很多教程会提示一些数据库的某些隔离级别是使用MVCC而不是锁的方案来实现的，说的好像用了MVCC就完全不需要锁。这是非常容易引起误解的。事务数据库对于写操作永远需要锁来避免脏写，即使是基于MVCC的数据库。所谓某个隔离级别使用MVCC不需要锁，仅仅是指在读取的时候是否需要锁。

所以，最不严格的隔离级别的隔离级别是允许脏读，但不允许脏写。这种隔离级别被称为Read Uncommitted。这种隔离级别一般不建议使用。事务应该是数据被修改的最小单位，而Read Uncommitted丧失了事务这个词本身存在的意义。虽然该隔离级别可以带来一些性能上的优势，但因为其容易造成数据由于并发操作带来的问题，所以应该用在不不太在意数据正确性的场景。但如果你的业务需要性能上的优势，就说明请求量很高，而请求量很高的业务一般很重要，不太可能不需要数据正确性。如果访问请求量不高，直接用默认的隔离级别（有的数据库是Read Committed，有的是Repeatable Read）就是了，没有必要去折腾数据库配置。 如果是高性能的简单数据操作（比如根据数据ID直接修改数据行），用Read Uncommitted是可行的。但既然这样，为什么不用一个正儿八经的NoSQL数据库（比如RocksDB），从而得到高的多写入性能？

Read Uncommitted在SQL92里被定义为最低级别的隔离。但在PostgreSQL中，Read Uncommitted压根就没有实现，设置Read Uncommitted等价于设置Read Committed。

**简单来说，对于事务性数据库，Read Uncommitted是鸡肋一般的存在。诸位可以无视之。**O(∩_∩)O哈哈哈~

2. Read Committed和Repeatable Read

把这俩种隔离级别放一起说是因为它们的基本原则是一样的：读不block读和写，写不block读。只不过是发生了并行读写的隔离效果不太一样。此外，它们两个对OLTP业务代码的编写的影响差不多——它们都无法解决写前提困境。在深入讨论之前，这里先复述一遍这俩隔离级别的意思。

Read Committed是指一个事务能看到另外一个事务对一条数据记录已经提交的修改。例如下面的操作序列（假设变量x的值一开始是0）：

这里可以看到事务A对x的两次读取，因为发生在事务B对x修改的前后，得到了不同的结果。事务A可以看到事务B已经提交的修改。

Repeatable Read是指一个事务一旦开始，反复读取一条数据记录，都会得到相同的结果。或者说，假如有两个事务A和B，A在B之前开始，那么B对数据的修改对于事务A总是不可见的。例如下面的操作序列（假设变量x的值一开始是0）：

Repeatable Read的直观感觉仿佛是给事务做一个整个数据库做了一个快照，所以很多时候这种隔离级别又被称为Snapshot Isolation。"快照"的功能在一些场景下非常重要，如：

数据备份。例如数据库S从数据库M中复制数据，但是同时M数据库又被持续修改。S需要拿到一个M的数据快照，但是又不能真的把M给停了。数据合法性检查。例如有两张数据表，一张记录了当时的交易总额，另外一张表记录了每个交易的金额。那么在读取数据时，如果没有快照的存在，交易金额的总和可能与当时的交易总额对不上，因为随着检查事务的进行，新的交易记录数据会被提交。这些新的提交会被检查事务看到。

在基于MVCC的数据库中，一般认为只实现了Read Committed和Repeatable Read两隔离级别。PostgreSQL在9.1以前，Serializable和Repeatable Read是一样的（PostgreSQL 9.1以后的Serializable增强了数据依赖性的检查）。

此外值得一提的是幻读的问题。在SQL92标准中提到了Repeatable Read中是可以出现幻读的——即一个事务尽管不能读取到后续其他事务对现有数据的修改，但是能够读取到插入的新数据。但是，基于MVCC的实现，Repeatable Read可以完全避免幻读（这岂不是更好）。无论MySQL还是PostgreSQL在Repeatable Read隔离级别都不会出现幻读。

3. MVCC

MVCC是"Multi-Version Concurrency Control"的缩写。名字看上去很吓唬人，有点不明觉厉，但是可以这样简单理解——对数据库的任何修改的提交都不会直接覆盖之前的数据，而是产生一个新的版本与老版本共存，使得读取时可以完全不加锁。这个版本一般用进行数据操作的事务ID(单调递增）来定义。MVCC大致可以这么实现： 每个数据记录携带两个额外的数据created_by_txn_id和deleted_by_txn_id。

当一个数据被insert时，created_by_txn_id记录下插入该数据的事务ID，deleted_by_txn_id留空。当一个数据被delete时，该数据的deleted_by_txn_id记录执行该删除的事务ID。当一个数据被update时，原有数据的deleted_by_txn_id记录执行该更新的事务ID，并且新增一条新的数据记录，其created_by_txn_id记录下更新该数据的事务ID

在另一个事务进行读取时，由隔离级别来控制到底取哪个版本。同时，在读取过程中，完全不加锁（除非用SELECT … FOR UPDATE强行加锁）。这样可以极大降低数据读取时因为冲突被Block的机会。

那么那些多出来的无用数据怎么被最终被清理呢？支持MVCC的数据库一般会有一个背景任务来定时清理那些肯定没用的数据。只要一个数据记录的deleted_by_txn_id不为空，并且比当前还没结束的事务ID中最小的一个还要小，该数据记录就可以被清理掉。在PostgreSQL中，这个背景任务叫做VACUUM进程；而在MySQL InnoDB中，叫做purge。

在PostgreSQL的实现中，MVCC产生的所有版本的节点都生成存储数据表的B+树的节点。新的节点和老的节点并存，只是上边的标记不同。这个实现的好处是选择读取哪个版本非常方便，可以和B+树的搜索算法合并到一起，还能兼顾SSI检测（下文会提到）。坏处是清理废弃数据相对麻烦。

MySQL采用Undo Log的实现。这种实现下，用于存储数据表的B+树节点总是只保留最新的数据，而老版本的数据被放在Undo Log里，并且以指针的形式关联起来，形成一个链表。这样，在查找老的版本时，需要按链表顺序查找，直到找到created_by_txn_id <= 当前事务ID的最新那条记录即可。这种实现的优缺点和PostgreSQL正相反，查询时会在B+树查找后多引入一个链表查询；但是清理废弃数据时会更简单，只要把Undo Log找到一个合适的位置一刀切了即可。 有了MVCC，Read Committed和Repeatable Read就的实现就很直观了：

对于Read Committed，每次读取时，总是取最新的，被提交的那个版本的数据记录。对于Repeatable Read，每次读取时，总是取created_by_txn_id小于等于当前事务ID的那些数据记录。在这个范围内，如果某一数据多个版本都存在，则取最新的。

有趣的是，隔离级别可以是一个Session级别的配置。即每一个Session可以在运行时选择自己希望使用什么隔离级别，也可以随时修改（只要当前没有尚未结束的事务）。每个Session的隔离级别和其他Session是什么隔离级别完全无关。Session只要根据自己的隔离级别，选择用MVCC提供的合适的版本即可。

MySQL InnoDB、PostgreSQL、Oracle （从版本4开始）、MS SQL Server（从版本2005开始）都实现了MVCC。值得一提的是MySQL InnoDB尽管一开始就实现了MVCC，但是之前很多人还在使用MyISAM存储引擎，而MyISAM根本就不支持事务，更不要提MVCC。直到MySQL 5.5.5，InnoDB才成为MySQL默认的搜索引擎。因此如果有想用MySQL做隔离级别实验的读者最好先弄清自己用的MySQL版本和存储引擎。

4. 写前提困境

尽管在MVCC的加持下Read Committed和Repeatable Read都可以得到很好的实现。但是对于某些业务代码来讲，在当前事务中看到/看不到其他的事务已经提交的修改的意义不是很大。这种业务代码一般是这样的：

先读取一段现有的数据在这个数据的基础上做逻辑判断或者计算；将计算的结果写回数据库。 这样第三步的写入就会依赖第一步的读取。但是在1和3之间，不管业务代码离得有多近，都无法避免其他事务的并发修改。换句话说，步骤1的数据正确是步骤3能够在业务上正确的前提。

在Repeatable Read下是解决不了这个问题的，因为在步骤3时，当前事务根本就无法看到另外一个事务对数据的修改。这个问题一般被称为Lost Updates。看这个案列，假设用Repeatable Read隔离级别实现一个计数器：

这时，事务A结束后，就会丢掉一次counter的计数。

而Read Commited尽管能够看到其他事务已经提交的修改，问题在于，在Read Commited，你必须重复写一句select语句才能拿到。而不管你反复读取多少次，不管这个select离得与下面的update有多近，理论上都无法避免丢失其他事务的修改。

简单来说，这个问题就是在修改的事务在提交时，无法确保这个修改的前提是否还可靠。这种问题我称之为写前提困境。 解决这类问题有3种办法：数据库支持某种代码块，这个代码块的执行是排他的；加悲观锁，把期望依赖的数据独占，在修改完成前不允许其他并发修改发生；加乐观锁，在事务提交的一刹那（注意是commit时，不是修改时），检查修改的依赖是不是没有被修改； 在事务性数据库中，第一种被称为Actual Serial Execution，第二种是加锁（手工或者自动）；第三种被称为Serializable Snapshot Isolation, SSI。

5. Actual Serial Execution

Actual Serial Execution是一种执行的效果，即一段代码在数据库服务器端执行时不会受到其他并发控制的干扰。但要达成这个效果并不简单。

最简单的实现方案是让整个数据库只能单线程跑。这样什么并发隔离保护的机制都可以不要，所有的数据不会有任何并发修改的问题。一些NoSQL的存储，如Redis、VoltDB都是这么实现的。但是他们这么实现是有原因的，因为他们都是基于内存的存储，其数据操作的延迟相对于网络IO几乎可以忽略不计。所以即使是单线程，配合nonblocking IO，他们的并发性能也可以非常高。但这个假设对事务性数据库并不成立，因为事务性数据库要操作磁盘/SSD。即便是SSD的写入速度，也会在数量级上低于内存。所以事务性数据库如果强行改成单线程，就会极大的损害并发性能。

此外，单线程存储因为只能使用单线程，所以一个实例只能使用一个CPU核心。在多核心机器上就会浪费资源。所以往往要单机启用多个实例。而一旦启用多个实例就意味着要提前对数据进行Partition，分配给多个实例。但是Partition会造成单Partion查询方便，跨越多个Partition的查询麻烦的问题。所以简单的说，这条路子可以走，但是有比较大的局限性，比较适合为特定业务做定制存储。

另外一种办法是用存储过程将业务逻辑包起来丢给数据库执行。但这样做其实不现实，因为存储过程本身并不具备原子性和隔离性。为了让存储过程中执行是排他的，依然需要在存储过程里声明一个事务。如果必要，可以声明当前的事务隔离级别为Serializable以避免写前提困境。例如Mysql InnoDB可以这样写。

sql复制代码CREATEPROCEDUREfoo_proc(INparam_1INT,INparam_2VARCHAR(100) )BEGINSETTRANSACTIONISOLATION_LEVELSERIALIZABLE;-- 可以设定下一个事务用Serializable隔离级别STARTTRANSACTION;-- 一系列操作代码……COMMIT;END;

这种做法其实等价于下面要讲的Serializable隔离级别。

顺便提一下，存储过程存在一系列使用上的问题，如不好开发，不好调试，不好版本管理，一旦写错可能会拖垮整个数据库服务器等。所以真的用起来先要仔细权衡是否值得使用它。

最后还有一个招数是用单SQL语句的事务。比如上面的计数器可以这样写：

ini复制代码UPDATEcounter_tblSETcounter = counter +1whereid= xxx;

这样写的确能保证排他性执行，因为这条语句自身可以成为一个事务，并且因为是UPDATE语句，所以必然会抢占X锁。锁的存在可以确保不会出现写前提困境。但这么做的前提是有办法把一个业务逻辑用一句修改类SQL表达。一个计数器的逻辑可以，但是复杂一些的业务就不行；或者在语法层面可行，但是写出来几百行的SQL，根本无法调试和维护。

6. 加锁和基于锁的Serializable

通过加锁可以有效的排除所有可能的竞争问题。在MySQL InnoDB中，Serializable隔离级别是依靠MVCC + 加更多的锁。以下摘自MySQL的文档

SERIALIZABLE This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... LOCK IN SHARE MODE if autocommit is disabled.

简单来讲就是所有的读取要加上共享锁。与MySQL不同，在PostgreSQL中，Serializable使用SSI实现，见下文的SSI的介绍。 数据库中经典的加锁的过程被称为两阶段加锁 (2 Phases Locking, 2PL)。注意这个词和两阶段提交（2PC）很像，但他们是截然不同的两个意思。所谓两阶段加锁是指：

加锁阶段：在事务过程中，根据不同的SQL指令加锁。释放锁阶段：锁定直到这个事务被提交或者回滚（包括等待超时造成回滚）时释放。 基于锁的Serializable的实现准则是：读要block写，写也要block读，读不block读。

还是考虑上面计数器的案列，在MySQL InnoDB Serializable隔离级别下的过程。

上面的案列解释了counter这条记录上的锁如何避免了counter的竞争问题。

实际上MySQL的Serializable除了锁记录，还会锁记录的间隙，避免意外的插入。这种锁概念上被称为区间锁(Range Lock)。MySQL InnoDB中的叫法是Gap Lock和Next-key Lock。

上文中有提到基于MVCC的Repeatable Read可以避免幻读。在基于锁的Serializable中做的更强硬，它会直接锁定以避免插入。

考虑下面的案列：

在MySQL中，不同的隔离级别内部实现使用不同的MVCC读取策略+不同种类的锁来完成。这就好像你春节在饭馆吃饭，得点套餐一样。那么如果这些隔离级别没有一个满足心意，或者希望根据业务逻辑实现一些定制优化，是不是可以不可以DIY一下呢？是可以的：

SELECT ... LOCK IN SHARE MODE -- 尝试将查询符合条件的记录加上共享锁，如果锁已经被占了就等待SELECT ... FOR UPDATE -- 尝试将符合查询条件的记录加上与等价UPDATE语句一样的锁，包括排他锁和区间锁

这些语句可以无视当前的隔离级别，完全按照你的心意来加锁。举个案列，假设有一个user数据表有id和name两列。id=3的name数据初始为"tom"。事务A和B都使用隔离级别Repeatable Read。

在MySQL中SELECT … FOR UPDATE会打破当前的Repeatable Read隔离级别，拿到另外一个事务提交的最新的数据；同样的行为在PostgreSQL执行的结果不同，PostgreSQL会检测出并发的数据修改而直接回滚事务。

基于锁的Serializable隔离级别，或者手工加锁，是可以根除任何并发冲突的，但是这是有代价的——大大的增加了锁的数量，同时也就增加了等待锁的时间以及死锁的机会。下面我们再看看SSI。

7. SSI和基于SSI实现的Serializable

相对于悲观锁的方案，相对应的乐观锁的方式就是SSI——Serialized Snopshot Isolation。它的大致意思是：本质上，整个事务还是Snapshot Isolation，但事务在进行过程中，除了对数据进行操作外，还要对整个事务的写前提——所有修改操作的依赖数据做追踪。当事务被commit时，当前事务会检查这个写前提是否被其他事务修改过，如果是，则回滚掉当前事务。PostgreSQL的Serializable基于SSI实现。

例如下面的是一个SSI隔离级别的案列。

那么问题在于如何侦测到这个修改已经发生了？基本的办法有：

在一个事务进行提交时，对于所有修改的数据，查看MVCC中是否已经有其他的版本已经提交了但是本事务因为snapshot机制没有读取到事务进行时，标记自身所有读取过的记录（就好像加共享锁，但是并不真的锁定什么）。另外一个事务如果提交了一个写操作，则反查这个写操作影响到的数据有哪些被读取中，并且读取他们的事务还没提交 SSI并非绝对优于锁的方案。悲观锁方案和乐观锁方案的权衡点在于，冲突是否足够多。如果冲突太多，SSI会造成大量的资源浪费（做了很多计算，但是就是commit不了）；如果冲突不是很多，加锁方案带来锁等待和死锁的负面效果更显著。所以在选取方案之前，先对业务造成的并发修改冲突量有一个估计。

三、锁的具体内容

在mysql中的锁看起来是很复杂的，因为有一大堆的东西和名词：排它锁，共享锁，表锁，页锁，间隙锁，意向排它锁，意向共享锁，行锁，读锁，写锁，乐观锁，悲观锁，死锁。这些名词有的博客又直接写锁的英文的简写--->X锁，S锁，IS锁，IX锁，MMVC...

锁的相关知识又跟存储引擎，索引，事务的隔离级别都是关联的....

这就给初学数据库锁的人带来不少的麻烦~于是我下面就简单整理一下数据库锁的知识点，希望大家看完会有所帮助。

1. MySQL锁分类（按粒度）

相对于其他的数据库而言，MySQL的锁机制比较简单，最显著的特点就是不同的存储引擎支持不同的锁机制。根据不同的存储引擎，MySQL中锁的特性可以大致归纳如下：

1.1 表锁：

开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低

1.2 行锁：

开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高

1.3 页锁：

开销和加锁速度介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般

从上述的特点可见，很难笼统的说哪种锁最好，只能根据具体应用的特点来说哪种锁更加合适。仅仅从锁的角度来说的话：

表锁更适用于以查询为主，只有少量按索引条件更新数据的应用；行锁更适用于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用。（PS：由于BDB已经被InnoDB所取代，我们只讨论MyISAM表锁和InnoDB行锁的问题）

不同的存储引擎支持的锁粒度是不一样的：

InnoDB行锁和表锁都支持！MyISAM只支持表锁！InnoDB只有通过索引条件检索数据才使用行级锁，否则，InnoDB将使用表锁

也就是说，

InnoDB的行锁是基于索引的！InnoDB的行锁是基于索引的！InnoDB的行锁是基于索引的！

敲黑板划重点，重要的事情说三遍！！！

2. 表锁

表锁下分为两种模式：

表读锁（Table Read Lock）表写锁（Table Write Lock）

从下图可以清晰看到，在表读锁和表写锁的环境下：

读读不阻塞读写阻塞写写阻塞读读不阻塞：当前用户在读数据，其他的用户也在读数据，不会加锁读写阻塞：当前用户在读数据，其他的用户不能修改当前用户读的数据，会加锁写写阻塞：当前用户在修改数据，其他的用户不能修改当前用户正在修改的数据，会加锁

从上面已经看到了：读锁和写锁是互斥的，读写操作是串行。

如果某个进程想要获取读锁，同时另外一个进程想要获取写锁。在mysql里边，写锁是优先于读锁的！

写锁和读锁优先级的问题是可以通过参数调节的：max_write_lock_count和low-priority-updates

值得注意的是：

MyISAM可以支持查询和插入操作的并发进行。 可以通过系统变量concurrent_insert来指定哪种模式，在MyISAM中它默认是：如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录。 但是InnoDB存储引擎是不支持的！

2.1 查询表级锁争用情况

可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定争夺：

mysql> show status like table%;

Variable_name

Value

Table_locks_immediate

2979

Table_locks_waited

0

2 rows in set (0.00 sec))

如果Table_locks_waited的值比较高，则说明存在着较严重的表级锁争用情况。

对MyISAM表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；对MyISAM表的写操作，则会阻塞其他用户对同一表的读和写操作；MyISAM表的读操作与写操作之间，以及写操作之间是串行的！当一个线程获得对一个表的写锁后，只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。

2.2 如何加表锁

MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。显式加锁基本上都是为了方便而已，并非必须如此。

给MyISAM表显示加锁，一般是为了在一定程度模拟事务操作，实现对某一时间点多个表的一致性读取。例如，有一个订单表orders，其中记录有各订单的总金额total，同时还有一个订单明细表order_detail，其中记录有各订单每一产品的金额小计 subtotal，假设我们需要检查这两个表的金额合计是否相符，可能就需要执行如下两条SQL：

sql复制代码Selectsum(total)fromorders;Selectsum(subtotal)fromorder_detail;

这时，如果不先给两个表加锁，就可能产生错误的结果，因为第一条语句执行过程中，order_detail表可能已经发生了改变。因此，正确的方法应该是：

sql复制代码Locktablesordersreadlocal, order_detailreadlocal;Selectsum(total)fromorders;Selectsum(subtotal)fromorder_detail;Unlocktables;

要特别说明以下两点内容。

上面的案列在LOCK TABLES时加了local选项，其作用就是在满足MyISAM表并发插入条件的情况下，允许其他用户在表尾并发插入记录，有关MyISAM表的并发插入问题，在后面的章节中还会进一步介绍。在用LOCK TABLES给表显式加表锁时，必须同时取得所有涉及到表的锁，并且MySQL不支持锁升级。也就是说，在执行LOCK TABLES后，只能访问显式加锁的这些表，不能访问未加锁的表；同时，如果加的是读锁，那么只能执行查询操作，而不能执行更新操作。其实，在自动加锁的情况下也基本如此，MyISAM总是一次获得SQL语句所需要的全部锁。这也正是MyISAM表不会出现死锁（Deadlock Free）的原因。注意，当使用LOCK TABLES时，不仅需要一次锁定用到的所有表，而且，同一个表在SQL语句中出现多少次，就要通过与SQL语句中相同的别名锁定多少次，否则也会出错！（1）对actor表获得读锁：mysql> lock table actor read;Query OK, 0 rows affected (0.00 sec)（2）但是通过别名访问会提示错误：mysql> select a.first_name,a.last_name,b.first_name,b.last_name from actor a,actor b where a.first_name = b.first_name and a.first_name = Lisa and a.last_name = Tom and a.last_name <> b.last_name;ERROR 1100 (HY000): Table a was not locked with LOCK TABLES（3）需要对别名分别锁定：mysql> lock table actor as a read,actor as b read;Query OK, 0 rows affected (0.00 sec)（4）按照别名的查询可以正确执行：mysql> select a.first\_name,a.last\_name,b.first\_name,b.last\_name from actor a,actor b where a.first\_name = b.first\_name and a.first\_name = Lisa and a.last\_name = Tom and a.last\_name <> b.last\_name;first_namelast_namefirst_namelast_nameLisaTomLISAMONROE1 row in set (0.00 sec)

3. 行锁

上边简单讲解了表锁的相关知识，我们使用Mysql一般是使用InnoDB存储引擎的。InnoDB和MyISAM有两个本质的区别：

InnoDB支持行锁InnoDB支持事务

从上面也说了：我们是很少手动加表锁的。表锁对我们程序员来说几乎是透明的，即使InnoDB不走索引，加的表锁也是自动的！

我们应该更加关注行锁的内容，因为InnoDB一大特性就是支持行锁！

InnoDB实现了 读锁（共享锁、S锁）和 写锁（排他锁、X锁)两种类型的行锁。

X锁，S锁，读锁，写锁，共享锁，排它锁其实总共就两个锁，只不过它们有多个名字罢了~

3.1 读锁（共享锁、S锁）

允许一个事务去读一行，阻止其他事务获得相同数据集的写锁。

读锁是共享的，多个客户可以同时读取同一个资源，但不允许其他客户修改。

3.2 写锁（排他锁、X锁)

允许获得写锁的事务更新数据，阻止其他事务取得相同数据集的读锁和写锁。

写锁是排他的，写锁会阻塞其他的写锁和读锁。

4. 意向锁（Intention Locks）

为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），意向锁也是数据库隐式帮我们做了，不需要程序员操心！

这两种意向锁都是表锁：

4.1 意向读锁（意向共享锁、IS锁）

事务打算给数据行加行读锁，事务在给一个数据行加读锁前必须先取得该表的意向读锁。

4.2 意向写锁（意向排他锁、IX锁）

事务打算给数据行加行写锁，事务在给一个数据行加写锁前必须先取得该表的意向写锁。

5. MVCC和事务的隔离级别

数据库事务有不同的隔离级别，不同的隔离级别对锁的使用是不同的，锁的应用最终导致不同事务的隔离级别

MVCC(Multi-Version Concurrency Control)多版本并发控制，可以简单地认为：MVCC就是行级锁的一个变种(升级版)。

事务的隔离级别就是通过锁的机制来实现，只不过隐藏了加锁细节 在表锁中我们读写是阻塞的，基于提升并发性能的考虑，MVCC一般读写是不阻塞的(所以说MVCC很多情况下避免了加锁的操作)

MVCC实现的读写不阻塞正如其名：多版本并发控制--->通过一定机制生成一个数据请求时间点的一致性数据快照（Snapshot)，并用这个快照来提供一定级别（语句级或事务级）的一致性读取。从用户的角度来看，好像是数据库可以提供同一数据的多个版本。

5.1 快照有两个级别

语句级:针对于Read committed隔离级别事务级别:针对于Repeatable read隔离级别

5.2 事务的隔离级别

我们在初学的时候已经知道，事务的隔离级别有4种：

Read uncommitted 会出现脏读，不可重复读，幻读Read committed 会出现不可重复读，幻读Repeatable read 会出现幻读(但在Mysql实现的Repeatable read配合gap锁不会出现幻读！)Serializable 串行，避免以上的情况！

5.2.1 Read uncommitted 会出现-->脏读：一个事务读取到另外一个事务未提交的数据

案列：A向B转账，A执行了转账语句，但A还没有提交事务，B读取数据，发现自己账户钱变多了！B跟A说，我已经收到钱了。A回滚事务【rollback】，等B再查看账户的钱时，发现钱并没有多。 出现脏读的原因是因为在读的时候没有加读锁，导致可以读取出还没释放锁的记录。

Read uncommitted过程：

css复制代码事务A读取记录(没有加任何的锁) 事务B修改记录(此时加了写锁，并且还没有commit-->也就没有释放掉写锁) 事务A再次读取记录(此时因为事务A在读取时没有加任何锁，所以可以读取到事务B还没提交的(没释放掉写锁)的记录

Read committed避免脏读的做法其实很简单：

在读取的时候生成一个版本号，直到事务其他commit被修改了之后，才会有新的版本号

Read committed过程：

css复制代码事务A读取了记录(生成版本号) 事务B修改了记录(此时加了写锁) 事务A再读取的时候，是依据最新的版本号来读取的(当事务B执行commit了之后，会生成一个新的版本号)，如果事务B还没有commit，那事务A读取的还是之前版本号的数据。

5.2.2 Read committed 会出现-->不可重复读：一个事务读取到另外一个事务已经提交的数据，也就是说一个事务可以看到其他事务所做的修改

注：A查询数据库得到数据，B去修改数据库的数据，导致A多次查询数据库的结果都不一样【危害：A每次查询的结果都是受B的影响的，那么A查询出来的信息就没有意思了】

上面也说了，Read committed是语句级别的快照！每次读取的都是当前最新的版本！

5.2.3 Repeatable read避免不可重复读是事务级别的快照！每次读取的都是当前事务的版本，即使被修改了，也只会读取当前事务版本的数据。

呃...如果还是不太清楚，我们来看看InnoDB的MVCC是怎么样的吧(摘抄《高性能MySQL》)

至于虚读(幻读)：是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。

注：和不可重复读类似，但虚读(幻读)会读到其他事务的插入的数据，导致前后读取不一致 MySQL的Repeatable read隔离级别加上GAP间隙锁已经处理了幻读了。

6. 乐观锁和悲观锁

无论是Read committed还是Repeatable read隔离级别，都是为了解决读写冲突的问题。

单纯在Repeatable read隔离级别下我们来考虑一个问题：

此时，用户李四的操作就丢失掉了：

丢失更新：一个事务的更新覆盖了其它事务的更新结果。 (ps:暂时没有想到比较好的案列来说明更新丢失的问题，虽然上面的案列也是更新丢失，但一定程度上是可接受的..不知道有没有人能想到不可接受的更新丢失案列呢...)

解决的方法：

使用Serializable隔离级别，事务是串行执行的！

乐观锁是一种思想，具体实现是，表中有一个版本字段，第一次读的时候，获取到这个字段。处理完业务逻辑开始更新的时候，需要再次查看该字段的值是否和第一次的一样。如果一样更新，反之拒绝。之所以叫乐观，因为这个模式没有从数据库加锁，等到更新的时候再判断是否可以更新。悲观锁是数据库层面加锁，都会阻塞去等待锁。

6.1 悲观锁

所以，按照上面的案列。我们使用悲观锁的话其实很简单(手动加行锁就行了)：

sql复制代码select*fromxxxxforupdate

在select 语句后边加了 for update相当于加了排它锁(写锁)，加了写锁以后，其他的事务就不能对它修改了！需要等待当前事务修改完之后才可以修改.

也就是说，如果张三使用select ... for update，李四就无法对该条记录修改了~

6.2 乐观锁

乐观锁不是数据库层面上的锁，是需要自己手动去加的锁。一般我们添加一个版本字段来实现：

具体过程是这样的：

张三 select * from table --->会查询出记录出来，同时会有一个version字段

李四select * from table --->会查询出记录出来，同时会有一个version字段

李四对这条记录做修改：update A set Name=lisi,version=version+1 where ID={id} and version={version}，判断之前查询到的version与现在的数据的version进行比较，同时会更新version字段

此时数据库记录如下：

张三也对这条记录修改： update A set Name=lisi,version=version+1 where ID={id} and version={version}，但失败了！因为当前数据库中的版本跟查询出来的版本不一致！

7. 间隙锁 GAP

当我们用范围条件检索数据而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合范围条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做间隙（GAP)。InnoDB也会对这个间隙加锁，这种锁机制就是所谓的间隙锁。

值得注意的是：间隙锁只会在Repeatable read隔离级别下使用~

案列：假如emp表中只有101条记录，其empid的值分别是1,2,...,100,101

Select * from emp where empid > 100 for update; 上面是一个范围查询，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的间隙加锁。

InnoDB使用间隙锁的目的有两个：

为了防止幻读(上面也说了，Repeatable read隔离级别下再通过GAP锁即可避免了幻读)满足恢复和复制的需要MySQL的恢复机制要求：在一个事务未提交前，其他并发事务不能插入满足其锁定条件的任何记录，也就是不允许出现幻读

8. 死锁

并发的问题就少不了死锁，在MySQL中同样会存在死锁的问题。

但一般来说MySQL通过回滚帮我们解决了不少死锁的问题了，但死锁是无法完全避免的，可以通过以下的经验参考，来尽可能少遇到死锁：

以固定的顺序访问表和行。比如对两个job批量更新的情形，简单方法是对id列表先排序，后执行，这样就避免了交叉等待锁的情形；将两个事务的sql顺序调整为一致，也能避免死锁。大事务拆小。大事务更倾向于死锁，如果业务允许，将大事务拆小。在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁概率。降低隔离级别。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁。为表添加合理的索引。可以看到如果不走索引将会为表的每一行记录添加上锁，死锁的概率大大增大。

9. 总结

上面说了一大堆关于MySQL数据库锁的东西，现在来简单总结一下。

表锁其实我们程序员是很少关心它的：

在MyISAM存储引擎中，当执行SQL语句的时候是自动加的。在InnoDB存储引擎中，如果没有使用索引，表锁也是自动加的。现在我们大多数使用MySQL都是使用InnoDB，InnoDB支持行锁：共享锁--读锁--S锁排它锁--写锁--X锁

在默认的情况下，select是不加任何行锁的~事务可以通过以下语句显示给记录集加共享锁或排他锁。

读锁、共享锁（S）：SELECT * FROM table\_name WHERE ... LOCK IN SHARE MODE写锁、排他锁（X)：SELECT * FROM table\_name WHERE ... FOR UPDATE

InnoDB基于行锁还实现了MVCC多版本并发控制，MVCC在隔离级别下的Read committed和Repeatable read下工作。MVCC能够实现读写不阻塞！

InnoDB实现的Repeatable read隔离级别配合GAP间隙锁已经避免了幻读！

乐观锁其实是一种思想，正如其名：认为不会锁定的情况下去更新数据，如果发现不对劲，才不更新(回滚)。在数据库中往往添加一个version字段来实现。悲观锁用的就是数据库的行锁，认为数据库会发生并发冲突，直接上来就把数据锁住，其他事务不能修改，直至提交了当前事务。

四、MySQL和PostgreSQL对比

通篇看下来你会发现MySQL和PostgreSQL对于并发控制的路子不太一样。这里稍微总结一下：

在MySQL中，很多开发者倾向于自己在默认隔离级别之外手工加锁。而PostgreSQL则建议尽量避免直接加锁，因为其Repeatable Read和Serializable的实现已经相当完善，开发者没必要自找麻烦。

五、日常开发

1. 大部分时候不要操这份心

因为很多互联网业务其实不需要特别在意并发时的正确性。比如一个社交网站大家发博客。一个用户自己管理自己的博客，几乎不太可能出并发性的问题。考虑如下的schema：

sql复制代码createtableblog ( blog_idintprimarykeyauto_increment, author_idintnotnull, titlevarchar(40)notnull,contentlongtextnotnulldefaultcreated_at datetimedefaultcurrent_timestamp, updated_at datetimedefaultcurrent_timestamponupdatecurrent_timestam, );

如果发生了并发的问题，就意味着用户同时在多个设备上编辑自己的博客，并几乎同时点击保存。这在现实中发生的几率非常少。即便发生了，数据会以稍后commit的事务为准。在业务上这种级别的正确性完全是可以接受的。本质上，这种场景天然的让数据发生了partition（本案列中author_id可以作为partition key），不同的事务只是修改自己那份partition而已，不会相互影响。

所以此时只需要使用数据库默认的隔离级别就可以了。基于MVCC的实现基本上免除了大部分的锁等待问题。

2. 为特定的业务场景做优化

那么什么时候会遇到并发修改问题？比如：

有全局数据需要增减。例如的库存数量/垫资额度要扣减。此时应该选择Serializable隔离级别或者手工SELECT … FOR UPDATE加锁。但是要特别留意，因为这样做会增加死锁等待/并发修改造成事务失败的问题发生的几率，所以尽量保证事务的粒度尽可能的小。避免一个巨大的事务长时间执行。

20～30年前对数据改动的业务逻辑的主流实现方法是，将全部业务逻辑实现在一个巨大的存储过程里，然后配合适当的隔离级别。现在的基于Web/App的业务流程早已转变成以交互为核心，所以业务逻辑会被拆解到若干个细小的事务里。其中一些业务流程（如第三方支付）不可避免的必须从事务中分离出来，做成分布式的事务。

需要读取大量数据。例如业务清算时需要读取一段时间所有的交易记录和资金流水。这种场景不属于OLTP，应该选择Repeatable Read隔离级别得到一个快照，并标记事务为只读SET TRANSACTION READ ONLY。这样会让数据库对事务的执行做优化，尽量避免冲突的发生。

海量数据插入到OLTP数据库。比如交易系统把每天用户的资产和收益计算后更新到OLTP数据库让用户访问。此时应该实现一个业务事务的概念。即不要依靠数据库的业务，而是依靠一个标记。当一个用户的数据正在更新时，应该避免用户看到部分被更新的数据。只有当数据全部更新完了，最后更新一下标记，让数据对用户可见。同时，对数据的更新应该拆解一个个小的事务，避免一个巨大的事务一次性完成更新。

简单的数据读取-更新场景。比如计数器。可以用单行UPDATE SQL的方式实现。前文中有提到。

特种业务的并发修改。比如共享文档编辑。这种情况下，无法只依靠数据库的并发控制，还必须引入业务级别的冲突检测，自动和手动的Resolve Conflict流程。这类问题找一个专题可以专门讨论一下。

3. 避免纠结于Repeatable Read和Read Committed的区别

上文已经提到了，这两个隔离级别都无法解决写前提困境。所以除非你是做数据库并发控制的开发者，或者是作为兴趣研究，不要去纠结于这些细节，也不要根据这些细节来有针对性的编写业务代码。业务的发展是完全不可控的，也许今天Read Committed可以，下次稍微改动一点点代码就必须要Repeatable Read。在常规开发中，因为一点点细节的改动就要造成整个并发控制方法发生更改，是需要尽量避免的情况。

4. 对并发冲突或者死锁尝试进行重试

在基于锁的实现中，可能会出现锁等待超时回滚；而在基于SSI的实现中，事务提交时可能会检测到并发修改，进而强行回滚事务。无论哪一种，都需要重试。需要编写代码来处理这种重试，并且需要根据业务需求确定重试的驱动者是谁——到底是后端代码，前端代码还是用户需要介入重试。

5. 对于MySQL考虑乐观锁

因为MySQL的隔离级别不支持SSI，所以可以考虑手工实现乐观锁。即自己在数据表里增加一个version列，并且在更新数据总是将修改之前的version放在UPDATE语句的where条件里。关于手工实现乐观锁的文章有很多，有些工具比如RoR可以半自动的产生乐观锁代码，这里就不赘述了。

但是很可惜，乐观锁的实现是有前提的，即修改的数据和修改的前提是同一份数据。如果这个前提不满足就无法实现。比如这个案列: 一组值班的客服可以打卡下班，但是要保证至少有5个客服在岗。假设有一个客服工作状态的表。

sql复制代码createtablesupportor_work_status ( supportor_idintprimarykeyactivebitnotnulldefaultb0);

需要始终这种表里active为1的行数必须高于5个。那么可能的代码为

ini复制代码intactiveCnt = db.query("select count(*) as cnt from supportor_work_status where active = 1");if(activeCnt >5) { db.execute("update supportor_work_status set active = 0 where supportor_id = ?, selfId); }

该事务在Repeatable Read下有机会造成少于5个人在岗。 此时，可以考虑物化冲突（Materialize Conflict）。即把这个冲突点变成一行数据，让数据库可以根据这行数据检测到冲突。比如上面的案列中，可以增加一个表supportor_active_count记录当前的在岗人数。并且对这条记录增加乐观锁即可。

6. 注意监控数据库的事务执行情况

一般监控都能做到监控数据库的CPU、磁盘、IO等资源的占用情况。除此之外，应当注意对事务的执行时间和数量做监控。数据库系统本身一般并不限制事务的执行时间（但是限制事务等待一个锁的时间）。一个执行数小时甚至数天的事务极大概率是有问题的，会带来如死锁增加，MVCC垃圾得不到清理等问题。