MySQL基础知识

天凉好个秋721
94 阅读31分钟

一、数据库基础

1、数据库范式

1NF(第一范式)

属性（对应于表中的字段）不能再被分割，也就是这个字段只能是一个值，不能再分为多个其他的字段了。1NF 是所有关系型数据库的最基本要求 ，也就是说关系型数据库中创建的表一定满足第一范式。

2NF(第二范式)

2NF 在 1NF 的基础之上，消除了非主属性对于码的部分函数依赖。如下图所示，展示了第一范式到第二范式的过渡。第二范式在第一范式的基础上增加了一个列，这个列称为主键，非主属性都依赖于主键。

bd1d31be3779342427fc9e462bf7f05c.png

一些重要的概念：

  • 函数依赖（functional dependency） ：若在一张表中，在属性（或属性组）X 的值确定的情况下，必定能确定属性 Y 的值，那么就可以说 Y 函数依赖于 X，写作 X → Y。
  • 部分函数依赖（partial functional dependency） ：如果 X→Y，并且存在 X 的一个真子集 X0，使得 X0→Y，则称 Y 对 X 部分函数依赖。比如学生基本信息表 R 中（学号，身份证号，姓名）当然学号属性取值是唯一的，在 R 关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；
  • 完全函数依赖(Full functional dependency) ：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。比如学生基本信息表 R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在 R 关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；
  • 传递函数依赖 ： 在关系模式 R(U)中，设 X，Y，Z 是 U 的不同的属性子集，如果 X 确定 Y、Y 确定 Z，且有 X 不包含 Y，Y 不确定 X，（X∪Y）∩Z=空集合，则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z 子集往往同属于某一个事物，因此可将其合并放到一个表中。比如在关系 R(学号 ,姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖。。

3NF(第三范式)

3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。符合 3NF 要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。比如在关系 R(学号 ,姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖，所以该表的设计，不符合 3NF 的要求。

总结

  • 1NF：属性不可再分。
  • 2NF：1NF 的基础之上，消除了非主属性对于码的部分函数依赖。
  • 3NF：3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。

2、MyISAM 和 InnoDB

MySQL 5.5 之前，MyISAM 引擎是 MySQL 的默认存储引擎，但是，MyISAM 不支持事务和行级锁，而且最大的缺陷就是崩溃后无法安全恢复。

5.5 版本之后，MySQL 引入了 InnoDB（事务性数据库引擎），MySQL 5.5 版本后默认的存储引擎为 InnoDB。

InnoDB的优势：

  • InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁；

  • InnoDB 提供事务支持，具有提交(commit)和回滚(rollback)事务的能力；

  • MyISAM 不支持，而 InnoDB 支持。当然根据《阿里开发手册》一般是不建议在数据库层面使用外键的。

  • 支持数据库异常崩溃后的安全恢复；

  • 支持MVCC（多版本并发控制，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存）。

MyISAM 和 InnoDB 存储引擎使用的锁：

  • MyISAM 采用表级锁(table-level locking)。
  • InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁

表级锁和行级锁对比：

  • 表级锁： MySQL 中锁定 粒度最大 的一种锁，对当前操作的整张表加锁，实现简单，资源消耗也比较少，加锁快，不会出现死锁。其锁定粒度最大，触发锁冲突的概率最高，并发度最低，MyISAM 和 InnoDB 引擎都支持表级锁。
  • 行级锁： MySQL 中锁定 粒度最小 的一种锁，只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。

InnoDB 存储引擎的锁的算法有三种：

  • Record lock：记录锁，单个行记录上的锁
  • Gap lock：间隙锁，锁定一个范围，不包括记录本身
  • Next-key lock：record+gap 临键锁，锁定一个范围，包含记录本身

二、数据库事务

数据库事务可以保证多个对数据库的操作（也就是 SQL 语句）构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库操作遵循：要么全部执行成功,要么全部不执行 。

1、何为 ACID 特性

关系型数据库（例如：MySQL、SQL Server、Oracle 等）事务都有 ACID 特性：

事务特性.png

  1. 原子性（Atomicity） ： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
  2. 一致性（Consistency）： 执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的；
  3. 隔离性（Isolation）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
  4. 持久性（Durability）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

2、数据库事务的实现原理

我们这里以 MySQL 的 InnoDB 引擎为例来简单说一下。

MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。

MySQL InnoDB 引擎通过 锁机制、MVCC 等手段来保证事务的隔离性（ 默认支持的隔离级别是 REPEATABLE-READ ）。

保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。

3、并发事务带来的问题

在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务（多个用户对同一数据进行操作）。并发虽然是必须的，但可能会导致以下的问题。

  • 脏读（Dirty read）: 指当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。
  • 丢失修改（Lost to modify）: 指两个事务同时读取了一个数据并做修改，那么其中一个事务的修改结果则会被丢失，称为丢失修改。 例如：事务 1 读取某表中的数据 A=20，事务 2 也读取 A=20，事务 1 修改 A=A-1，事务 2 也修改 A=A-1，最终结果 A=19，事务 1 的修改被丢失。
  • 不可重复读（Unrepeatable read）: 在一个事务开启过程中，当前事务读取到了另一事务提交的修改，导致在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
  • 幻读（Phantom read）: 幻读与不可重复读类似。在一个事务开启过程中，读取到另一个事务提交导致的数据条目的新增或删除，导致在一个事务内两次读到的数据条数不一致，所以称为幻读。

不可重复读和幻读区别：

不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除比如多次读取一条记录发现记录增多或减少了。

4、事务的隔离级别

READ-UNCOMMITTED(读未提交)：如果一个事务读到了另一个未提交事务修改过的数据，那么这种隔离级别就称为未提交读。

READ-COMMITTED(读已提交)： 如果一个事务只能读到另一个已经提交的事务修改过的数据，并且其他事务每对该数据进行一次修改并提交后，该事务都能查询得到最新值，那么这种隔离级别就称为已提交读。可以阻止脏读，但仍然可能发生不可重复读和幻读。

REPEATABLE-READ(可重复读取)： 一个事务对同一字段的多次读取结果都是一致的，即使期间其他事务修改了该记录的值并且提交，该事务再次读取时，读到的仍是第一次读到的值，而不是每次读到不同的数据。那么这种隔离级别就称为可重复读。可以阻止脏读和不可重复读，但幻读仍有可能发生。

SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

三、MySQL事务隔离实现原理

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读），并不保证避免幻读，需要应用使用加锁读来保证。

那么MySQL是如何保证多事务并发的情况保证事务隔离性的呢？这里就要引出MVCC（Multi-Version Concurrency Control）即多版本并发控制和MySQL的锁机制啦。

1、undo log

undo log 是 MVCC 实现的一个重要依赖，所以在详细介绍 MVCC 前，我们先来介绍 undo log 是什么。

undo log 与 redo log 一起构成了 MySQL 事务日志，并且日志先行原则 WAL 除了包含 redo log 外，也包括 undo log，事务中的每一次修改，innodb 都会先记录对应的 undo log 记录。

redo log和undo log的不同：

  • redo log 用于数据的灾后重新提交不同，undo log 主要用于数据修改的回滚；
  • redo log 记录的是物理页的修改，undo log 记录的是逻辑日志

undo日志主要分成两种：

  • insert undo log 代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃
  • update undo log 事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

2、当前读和快照读

innodb 拥有一个自增的全局事务 ID，每当一个事务开启，在事务中都会记录当前事务的唯一 id，而全局事务 ID 会随着新事务的创建而增长。同时，新事务创建时，事务系统会将当前未提交的所有事务 ID 组成的数组传递给这个新事务，本文的下面段落我们成这个数组为 TRX_ID 集合。

快照读

每当一个事务更新一条数据时，都会在写入对应的 undo log 日志后将这行记录的隐藏字段 DB_TRX_ID 更新为当前事务的事务 ID，用来表明最新更新该数据的事务是该事务。

当另一个事务去 select 数据时，读到该行数据的 DB_TRX_ID 不为空并且 DB_TRX_ID 与当前事务的事务 ID 是不同的，这就说明这一行数据是另一个事务修改并提交的。

那么数据究竟是在当前事务开启前提交的还是在当前事务开启后提交的呢？

image-20211217131713213.png

如上图所示，有了上文提到的 TRX_ID 集合，就很容易判断这个问题了，如果这一行数据的 DB_TRX_ID 在 TRX_ID 集合中或大于当前事务的事务 ID，那么就说明这行数据是在当前事务开启后提交的，否则说明这行数据是在当前事务开启前提交的。 对于当前事务开启后提交的数据，当前事务需要通过隐藏的 DB_ROLL_PTR 字段找到 undo log，然后进行逻辑上的回溯才能拿到事务开启时的原数据。 这个通过 undo log + 数据行获取到事务开启时的原始数据的过程就是“快照读”。

快照读的实现是基于多版本并发控制，即MVCC,可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。

当前读

事务每次读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁，主要包含以下事务操作：

  1. insert
  2. update
  3. select … lock in share mode（共享锁）
  4. select … for update（排它锁）

3、MVCC

数据库的并发场景

  • 读—读：不存在任何问题，也不需要并发控制；
  • 读—写：有线程安全问题，可能会造成事务隔离性问题，遇到脏读、幻读、不可重复读；
  • 写—写：有线程安全问题，可能会造成更新丢失问题。

而MVCC（Multi-Version Concurrency Control ，多版本并发控制）就是一种并发控制的方法，用于当数据库采用READ COMMITTD、REPEATABLE READ这两种事务隔离级别，在执行SEELCT操作时访问记录的版本链的过程，目的是实现快照读下不同事务的读—写操作不加锁并发执行，从而提升系统性能，它可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题。

版本链

对于使用InnoDB存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列（row_id并不是必要的，我们创建的表中有主键或者非NULL唯一键时都不会包含row_id列）：

  • trx_id ：事务ID，记录创建这条记录/最后一次修改该记录的事务ID；

  • roll_pointer ：回滚指针，指向这条记录的上一个版本。

每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表。

对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。

a7fad862d80f184f1f117d93cd9090ba.png

Read View（读视图）

Read View是事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大)

对于使用READ UNCOMMITTED隔离级别的事务来说，直接读取记录的最新版本就好了，对于使用SERIALIZABLE隔离级别的事务来说，使用加锁的方式来访问记录。对于使用READ COMMITTED和REPEATABLE READ隔离级别的事务来说，就需要用到我们上边所说的版本链了，核心问题就是：需要判断一下版本链中的哪个版本是当前事务可见的。所以设计InnoDB的大叔提出了一个ReadView的概念，这个ReadView中主要包含当前系统中还有哪些活跃的读写事务，把它们的事务id放到一个列表中，我们把这个列表命名为为m_ids。这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：

  • 如果被访问版本的trx_id属性值小于m_ids列表中最小的事务id，表明生成该版本的事务在生成ReadView前已经提交，所以该版本可以被当前事务访问。
  • 如果被访问版本的trx_id属性值大于m_ids列表中最大的事务id，表明生成该版本的事务在生成ReadView后才生成，所以该版本不可以被当前事务访问。
  • 如果被访问版本的trx_id属性值在m_ids列表中最大的事务id和最小事务id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性，依此类推，直到版本链中的最后一个版本，如果最后一个版本也不可见的话，那么就意味着该条记录对该事务不可见，查询结果就不包含该记录。

在MySQL中，READ COMMITTED和REPEATABLE READ隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同。

  • READ COMMITTED --- 每次读取数据前都生成一个ReadView
  • REPEATABLE READ --- 只在第一次读取数据时生成一个ReadView

可重复读隔离级别的不可重复读和幻读问题

对于正常的 select 查询 innodb 实际上进行的是快照读，即通过判断读取到的行的 DB_TRX_ID 与 DB_ROLL_PTR 字段指向的 undo log 回溯到事务开启前或当前事务最后一次更新的数据版本，从而在这样的场景下避免了可重复读与幻读的问题。

针对已存在的数据，insert 和 update 操作虽然是进行当前读，但 insert 与 update 操作后，该行的最新修改事务 ID 为当前事务 ID，因此读到的值仍然是当前事务所修改的数据，不会产生不可重复读的问题。

但如果当前事务更新到了其他事务新插入并提交了的数据，这就会造成该行数据的 DB_TRX_ID 被更新为当前事务 ID，此后即便进行快照读，依然会查出该行数据，产生幻读（其他事务插入或删除但未提交该行数据的情况下会锁定该行，造成当前事务对该行的更新操作被阻塞，所以这种情况不会产生幻读问题）

我们实际来看一个例子。首先，我们创建一个表：

CREATE TABLE `test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `value` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

然后我们插入三条初始数据：

INSERT INTO `test` (`value`) VALUES (1), (2), (3)

接下来我们在两个窗口中分别开启一个事务并查询出现有数据：

0c9f470819684156cfdc27c682db4def.png

我们在其中一个事务中先更新 id 为 1 的数据，再插入一条 id 为 4 的数据，再删除 id 为 2 的数据，然后，在另一个事务中查询，可以看到此时查询出来的仍然是事务开启时的初始数据，说明当前隔离级别和场景下并没有脏读的问题存在：

20190911224236136.png

此时，我们提交所有的修改，接着在另一个事务中查询，可以看到此时查询到的结果仍然是事务开启前的原始数据，说明当前隔离级别和场景下并没有不可重复读和幻读的问题存在：

2019091122425048.png

那么接下来，我们在未提交的这个事务中执行一条修改，可以看到，本应在事务中只影响一行的 update 操作返回了 changed: 2，接着，我们查询结果出现了 id 为 4 的行，说明了幻读问题的存在【update当前读会读最新数据】：

20190911224305759.png

4、bin log

binlog 即二进制日志，他记录了引起或可能引起数据库改变事件，包括事件发生的时间、开始位置、结束位置等信息，select、show 等查询语句不会引起数据库改变，因此不会被记录在 binlog 中；

对于事务的执行，只有事务提交时才会一次性写入 binlog，对于非事务操作，则每次语句执行成功后都会直接写入 binlog。

因此，基于 binlog，我们可以看到每一次对数据库的修改是在何时以何种方式执行的，从而可以实现对任意条操作的回滚，mysql 的主从同步机制也是依赖 binlog 来实现的，binlog 让从数据库可以精准还原主库的每一个操作。

5、redo log

在工程存储项目中，有一个重要的概念，那就是 crash safe，即当服务器突然断电或宕机，需要保证已提交的数据或修改不会丢失，未提交的数据能够自动回滚，这就是 mysql ACID 特性中的一个十分重要的特性 -- Atomicity 原子性。

数据库依靠 binlog 是无法保证 crash safe 的，因为 binlog 是事务提交时写入的，如果在 binlog 缓存中的数据持久化到硬盘之前宕机或断电，在服务器恢复工作后，由于 binlog 缺失一部分已提交的操作数据，而主数据库中实际上这部分操作已经存在，从数据库因此无法同步这部分操作，从而造成主从数据库数据不一致，这是很严重的。

但实际上，innodb 存储引擎是拥有 crash safe 能力的，那么他是用什么机制来实现呢？本文我们就来详细说明

MySQL的执行过程

无论使用任何存储引擎，只要开启相应配置，mysql 都会记录 binlog，但 MyISAM 引擎并没有提供 crash safe 能力，而 InnoDB 则提供了灾后恢复能力，这是为什么呢？

这和 mysql 整体的分层有关，我们需要首先了解一下一条 sql 语句是如何执行的

15ff4aeb110986b62a169308b58d333b.png

mysql 主要分为两层，与客户端直接交互的是 server 层，包括连接的简历和管理、词法分析、语法分析、执行计划与具体 sql 的选择都是在 server 层中进行的，binlog 就是在 server 层中由 mysql server 实现的，而 innodb 作为具体的一个存储引擎，他通过 redolog 实现了 crash safe 的支持。

redo log的写入

mysql 有一个基本的技术理念，那就是 WAL，即 Write-Ahead Logging，先写日志，再写磁盘，从而保证每一次操作都有据可查，这里所说的“先写日志”中的日志就包括 innodb 的 redolog

redolog 与持续向后添加的 binlog 不同，他只占用预先分配的一块固定大小的磁盘空间，在这片空间中，redolog 采用循环写入的方式写入新的数据

054fd37784f79e521dca96693e976049.png

同时，binlog 是以每条操作语句为单位进行记录的，而 redolog 则是以数据页来进行记录的，他记录了每个页上的修改，所以一个事务中可能分多次多条写入 redolog。

crash safe 与两阶段提交

每条 redolog 都有两个状态 -- prepare 与 commit 状态

例如对于一张 mysql 表，我们执行一条 SQL 语句：

CREATE TABLE `A` (
    `ID` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `C` int(10) NOT NULL DEFAULT 0, 
    PRIMARY KEY (`ID`)
) ENGINE=InnoDB

UPDATE A set C=C+1 WHERE ID=2

实际上，mysql 数据库会进行以下操作（下图中深色的是 mysql server 层所做的操作，浅色部分则是 innodb 存储引擎进行的操作）：

a70511f707b15cc4768cb82ceab4d4b5.png

可以看到，在写入 binlog 及事务提交前，innodb 先记录了 redolog，并标记为 prepare 状态，在事务提交后，innodb 会将 redolog 更新为 commit 状态，这样在异常发生时，就可以按照下面两条策略来处理：

  1. 当异常情况发生时，如果第一次写入 redolog 成功，写入 binlog 失败，MySQL 会当做事务失败直接回滚，保证了后续 redolog 和 binlog 的准确性
  2. 如果第一次写入 redolog 成功，binlog 也写入成功，当第二次写入 redolog 时候失败了，那数据恢复的过程中，MySQL 判断 redolog 状态为 prepare，且存在对应的 binlog 记录，则会重放事务提交，数据库中会进行相应的修改操作。

整个过程是一个典型的两阶段提交过程，由 binlog 充当了协调者的角色，针对每一次日志写入，innodb 都会随之记录一个 8 字节序列号 -- LSN（日志逻辑序列号 log sequence number），他会随着日志写入不断单调递增。

binlog、DB 中的数据、redolog 三者就是通过 LSN 关联到一起的，因为数据页上记录了 LSN、日志开始与结束均记录了 LSN、刷盘节点 checkpoint 也记录了 LSN，因此 LSN 成为了整套系统中的全局版本信息。

当异常发生并重新启动后，innodb 会根据出在 prepare 状态的 redo log 记录去查找相同 LSN 的 binlog、数据记录，从而实现异常后的恢复。

redo log 的组织

redo log 是以“块”为单位进行存储的，称之为“redo log block”，每个块的大小是 512 字节。

以块为单位存储的原因是他和磁盘扇区的大小是相同的，从而保证在异常情况发生时不会出现部分写入成功产生的脏数据。

四、MySQL的锁机制

实现并发控制的主要手段分为乐观并发控制和悲观并发控制两种。乐观锁比较适用于读多写少的情况(多读场景)，悲观锁比较适用于写多读少的情况(多写场景)。

1、悲观锁

悲观锁（Pessimistic Concurrency Control）就是在操作数据时，认为此操作会出现数据冲突，所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作。该锁由数据库实现，调用相关语句即可使用。

悲观锁，具有强烈的独占和排他特性，主要分为共享锁和排他锁：

  • 共享锁【shared locks】又称为读锁，简称 S 锁。顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。并且如果事务对数据加上共享锁后，则其他事务只能对该数据再加共享锁，不能加排他锁。
  • 排他锁【exclusive locks】又称为写锁，简称 X 锁。顾名思义，排他锁就是不能与其他锁并存，如果一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁。获取排他锁的事务可以对数据行读取和修改。

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。 悲观锁的实现，往往依靠数据库提供的锁机制。在数据库中，悲观锁的流程如下：

  1. 在对记录进行修改前，先尝试为该记录加上排他锁(exclusive locks)。
  2. 如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
  3. 如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
  4. 期间如果有其他对该记录做修改或加排他锁的操作，都会等待解锁或直接抛出异常。

2、乐观锁

乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果冲突，则返回给用户异常信息，让用户决定如何去做。乐观锁适用于读多写少的场景，这样可以提高程序的吞吐量。

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

乐观锁需要自定义实现，常用的实现方式：

  • CAS 实现：Java 中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现方式。
  • 版本号控制：一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会 +1。当线程 A 要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值与当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

3、CAS

CAS (Compare and Swap) 即比较并交换。是解决多线程并行情况下使用锁造成性能损耗的一种机制，CAS 操作包含三个操作数——内存位置(V)、预期原值(A)和新值(B)。

如果内存位置的值(V)与预期原值(A)相匹配，那么处理器会自动将该位置值更新为新值(B)。否则，处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。

CAS 有效地说明了“我认为位置(V)应该包含值(A)。如果包含该值，则将新值(B)放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可” 。

CAS的底层：当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。举个扣减库存的例子，通过乐观锁的实现如下：

// 查询出商品信息，得quantity = 3,即id=1的商品数量为3
select quantity from items where id = 1;
// 当且仅当该商品的数量依然为3时，修改商品库存为2
update items set quantity = 2 where id = 1 and quantity = 3;

ABA问题

7038163-8ca34c3adccb7ca6.webp

ABA：如果另一个线程修改V值假设原来是A，先修改成B，再修改回成A。当前线程的CAS操作无法分辨当前V值是否发生过变化。

一个比较好的解决方法，就是通过一个单独的可以顺序递增的version字段。优化如下：

7038163-a23fb455b893f97f.webp

乐观锁每次在执行数据修改操作时，都会带上一个版本号，一旦版本号和数据的版本号一致就可以执行修改操作并对版本号执行 +1 操作，否则就执行失败。因为每次操作的版本号都会随之增加，所以不会出现 ABA 问题。除了 version 以外，还可以使用时间戳，因为时间戳天然具有顺序递增性。

高并发下的优化方案：

以上 SQL 其实还是有一定的问题的，就是一旦遇上高并发的时候，就只有一个线程可以修改成功，那么就会存在大量的失败。对于像淘宝这样的电商网站，高并发是常有的事，总让用户感知到失败显然是不合理的。所以，还是要想办法减少乐观锁的粒度。一个比较好的建议，就是减小乐观锁力度，最大程度的提升吞吐率，提高并发能力！如下：

// 修改商品库存
update item 
set quantity = quantity - 1
where id = 1 and quantity - 1 > 0

以上 SQL 语句中，如果用户下单数为 1，则通过quantity - 1 > 0的方式进行乐观锁控制。在执行过程中，会在一次原子操作中查询一遍 quantity 的值，并将其扣减掉 1。

高并发环境下锁粒度把控是一门重要的学问。选择一个好的锁，在保证数据安全的情况下，可以大大提升吞吐率，进而提升性能。

CAS典型应用

java.util.concurrent.atomic包下的类大多是使用 CAS 操作来实现的，比如AtomicInteger、AtomicBoolean、AtomicLong。一般在竞争不是特别激烈的时候，使用该包下的原子操作性能比使用synchronized关键字的方式高效的多(查看 getAndSet()，可知如果资源竞争十分激烈的话，这个 for 循环可能会持续很久都不能成功跳出。不过这种情况可能需要考虑降低资源竞争才是)。 在较多的场景都可能会使用到这些原子类操作。一个典型应用就是计数了，在多线程的情况下需要考虑线程安全问题。

常见的自增计数实现如下：

public class Increment {
    private int count = 0;
    public void add() {
        count++;
    }
}

在并发环境下这种对 count 进行自增运算是不安全的，因为count++不是原子操作，而是三个原子操作的组合（取值、加一和回写），这不能保证线程都是依次完整执行完自增操作。

并发环境下count++不安全问题的解决方案：

方案一：synchronized加锁

public class Increment {
    private int count = 0;
    public synchronized void add() {
        count++;
    }
}

但是引入synchronized会造成多个线程排队的问题，相当于让各个线程串行化了，类似于悲观锁的实现，这种锁显得“太重了”。

方案二：Atomic原子类

//import java.util.concurrent.atomic.AtomicInteger;
public static void main(String[] args) {
    public static AtomicInteger count = new AtomicInteger(0);
    public static void increase() {
        count.incrementAndGet();
    }
}

Java 并发包下面提供了一系列的 Atomic 原子类，比如说 AtomicInteger,多个线程可以并发的执行 AtomicInteger 的 incrementAndGet()，意思就是把 count 的值累加 1，接着返回累加后最新的值。实际上，Atomic 原子类底层用的不是传统意义的锁机制，而是无锁化的 CAS 机制，通过 CAS 机制保证多线程修改一个数值的安全性。

CAS性能优化

在大量线程高并发更新 AtomicInteger 的时候，这会有大量的更新失败线程，会导致大量线程空循环，自旋转，性能和效率都不是特别好。那么如何优化呢？

Java8 有一个新的类，LongAdder，它就是尝试使用分段 CAS 以及自动分段迁移的方式来大幅度提升多线程高并发执行 CAS 操作的性能。

参考文章

MySQL事务隔离级别和MVCC

MySQL的可重复读级别能解决幻读吗

正确的理解MySQL的MVCC及实现原理

avatar
文章
阅读
粉丝