在高并发场景下，不考虑其他中间件的情况下，数据库会存在以下场景：
读读：不存在任何问题，也不需要并发控制。
读写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读。
写写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失。
针对以上问题，SQL 标准规定不同隔离级别下可能发生的问题不一样：
MySQL 四大隔离级别：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| READ UNCOMMITTED：未提交读 | 可能发生 | 可能发生 | 可能发生 |
| READ COMMITTED：已提交读 | 解决 | 可能发生 | 可能发生 |
| REPEATABLE READ：可重复读 | 解决 | 解决 | 可能发生 |
| SERIALIZABLE：可串行化 | 解决 | 解决 | 解决 |
可以看到，MySQL 在 REPEATABLE READ 隔离级别实际上就解决了不可重复度问题，基本解决了幻读问题，但在极端情况下仍然存在幻读现象。
那么有什么方式来解决呢？一般来说有两种方案：
1️⃣ 读操作 MVCC ，写操作加锁
对于读，在 RR 级别的 MVCC 下，当一个事务开启的时候会产生一个 ReadView，然后通过 ReadView 找到符合条件的历史版本，而这个版本则是由 undo 日志构建的，而在生成 ReadView 的时候，其实就是生成了一个快照，所以此时的 SELECT 查询也就是快照读（或者一致性读），我们知道在 RR 下，一个事务在执行过程中只有第一次执行 SELECT 操作才会生成一个 ReadView，之后的 SELECT 操作都复用这个 ReadView，这样就避免了不可重复读和很大程度上避免了幻读的问题。
对于写，由于在快照读或一致性读的过程中并不会对表中的任何记录做加锁操作并且 ReadView 的事务是历史版本，而对于写操作的最新版本两者并不会冲突，所以其他事务可以自由的对表中的记录做改动。
2️⃣ 读写操作都加锁
如果我们的一些业务场景不允许读取记录的旧版本，而是每次都必须去读取记录的最新版本，比方在银行存款的事务中，你需要先把账户的余额读出来，然后将其加上本次存款的数额，最后再写到数据库中。在将账户余额读取出来后，就不想让别的事务再访问该余额，直到本次存款事务执行完成，其他事务才可以访问账户的余额。这样在读取记录的时候也就需要对其进行加锁操作，这样也就意味着读操作和写操作也像写-写操作那样排队执行。
对于脏读，是因为当前事务读取了另一个未提交事务写的一条记录，但如果另一个事务在写记录的时候就给这条记录加锁，那么当前事务就无法继续读取该记录了，所以也就不会有脏读问题的产生了。
对于不可重复读，是因为当前事务先读取一条记录，另外一个事务对该记录做了改动之后并提交之后，当前事务再次读取时会获得不同的值，如果在当前事务读取记录时就给该记录加锁，那么另一个事务就无法修改该记录，自然也不会发生不可重复读了。
对于幻读，是因为当前事务读取了一个范围的记录，然后另外的事务向该范围内插入了新记录，当前事务再次读取该范围的记录时发现了新插入的新记录，我们把新插入的那些记录称之为幻影记录。
怎么理解这个范围？如下：
假如表 user 中只有一条id=1的数据。
当事务 A 执行一个id = 1的查询操作，能查询出来数据，如果是一个范围查询，如 id in(1,2)，必然只会查询出来一条数据。
此时事务 B 执行一个id = 2的新增操作，并且提交。
此时事务 A 再次执行id in(1,2)的查询，就会读取出 2 条记录，因此产生了幻读。
注：由于 RR 可重复读的原因，其实是查不出 id = 2的记录的，所以如果执行一次 update ... where id = 2，再去范围查询就能查出来了。
采用加锁的方式解决幻读问题就有不太容易了，因为当前事务在第一次读取记录时那些幻影记录并不存在，所以读取的时候加锁就有点麻烦，因为并不知道给谁加锁。
那么 InnoDB 是如何解决的呢？我们先来看看 InnoDB 存储引擎有哪些锁。
在 MySQL 官方文档 中，InnoDB 存储引擎介绍了以下几种锁：
同样，看起来仍然一头雾水，但我们可以按照学习 JDK 中锁的方式来进行分类：
什么是锁的粒度？所谓锁的粒度就是你要锁住的范围是多大。
比如你在家上卫生间，你只要锁住卫生间就可以了，不需要将整个家都锁起来不让家人进门吧，卫生间就是你的加锁粒度。
怎样才算合理的加锁粒度呢？
其实卫生间并不只是用来上厕所的，还可以洗澡，洗手。这里就涉及到优化加锁粒度的问题。
你在卫生间里洗澡，其实别人也可以同时去里面洗手，只要做到隔离起来就可以，如果马桶，浴缸，洗漱台都是隔开相对独立的（干湿分离了属于是），实际上卫生间可以同时给三个人使用，当然三个人做的事儿不能一样。这样就将锁的粒度细化了，你在洗澡时只需将浴室门关上，他人仍然可以进去洗手。若在设计卫生间时未将不同的功能区域分隔开，则无法最大化利用卫生间资源。
同样，在 MySQL 中也存在锁的粒度。通常分为三种，行锁，表锁和页锁。
在共享锁和独占锁的介绍中其实都是针对某一行记录的，所以也可以称之为行锁。
对一条记录加锁影响的也只是这条记录而已，所以行锁的锁定粒度在 MySQL 中是最细的。InnoDB 存储引擎默认锁就是行锁。
它具有以下特点：
锁冲突概率最低，并发性高
由于行锁的粒度小，所以发生锁定资源争用的概率也最小，从而锁冲突的概率就低，并发性越高。
开销大，加锁慢
锁是非常消耗性能的，试想一下，如果对数据库的多条数据加锁，必然会占用很多资源，而对于加锁需要等待之前的锁释放才能加锁。
会产生死锁
关于什么是死锁，可以往下看。
表级锁为表级别的锁定，会锁定整张表，可以很好的避免死锁，也是 MySQL 中最大颗粒度的锁定机制。
MyISAM 存储引擎的默认锁就是表锁。
它具有以下特点：
开销小，加锁快
由于是对整张表加锁，速度必然快于单条数据加锁。
不会产生死锁
都对整张表加锁了，其他事务根本拿不到锁，自然也不会产生死锁。
锁粒度大，发生锁冲突概率大，并发性低
页级锁是 MySQL 中比较独特的一种锁定级别，在其他数据库管理软件中并不常见。
页级锁的颗粒度介于行级锁与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处理能力同样也是介于上面二者之间。另外，页级锁和行级锁一样，会发生死锁。
| 行锁 | 表锁 | 页锁 | |
|---|---|---|---|
| 锁的粒度 | 小 | 大 | 两者之间 |
| 加锁效率 | 慢 | 快 | 两者之间 |
| 冲突概率 | 低 | 高 | - |
| 并发性能 | 高 | 低 | 一般 |
| 性能开销 | 大 | 小 | 两者之间 |
| 是否死锁 | 是 | 否 | 是 |
在 MySQL 中数据的读取主要分为当前读和快照读：
快照读
快照读，读取的是快照数据，不加锁的普通 SELECT 都属于快照读。
SELECT * FROM table WHERE ...
当前读
当前读就是读的是最新数据，而不是历史的数据，加锁的 SELECT，或者对数据进行增删改都会进行当前读。
SELECT * FROM table LOCK IN SHARE MODE; SELECT FROM table FOR UPDATE; INSERT INTO table values ... DELETE FROM table WHERE ... UPDATE table SET ...
而在大多数情况下，我们操作数据库都是当前读的情形，而在并发场景下，既要允许读-读情况不受影响，又要使写-写、读-写或写-读情况中的操作相互阻塞，就需要用到 MySQL 中的共享锁和独占锁。
共享锁（Shared Locks），也可以叫做读锁，简称 S 锁。可以并发的读取数据，但是任何事务都不能对数据进行修改。
独占锁（Exclusive Locks），也可以叫做排他锁或者写锁，简称 X 锁。若某个事物对某一行加上了排他锁，只能这个事务对其进行读写，在此事务结束之前， 其他事务不能对其进行加任何锁，其他进程可以读取，不能进行写操作，需等待其释放。
来分析一下获取锁的情形：假如存在事务 A 和事务 B
事务 A 获取了一条记录的 S 锁，此时事务 B 也想获取该条记录的 S 锁，那么事务 B 也能获取到该锁，也就是说事务 A 和事务 B 同时持有该条记录的 S 锁。
如果事务 B 想要获取该记录的 X 锁，则此操作会被阻塞，直到事务 A 提交之后将 S 锁释放。
如果事务 A 首先获取的是 X 锁，则不管事务 B 想获取该记录的 S 锁还是 X 锁都会被阻塞，直到事务 A 提交。
因此，我们可以说 S 锁和 S 锁是兼容的， S 锁和 X 锁是不兼容的， X 锁和 X 锁也是不兼容的。
意向共享锁（Intention Shared Lock），简称 IS 锁。当事务准备在某条记录上加 S 锁时，需要先在表级别加一个 IS 锁。
意向独占锁（Intention Exclusive Lock），简称 IX 锁。当事务准备在某条记录上加 X 锁时，需要先在表级别加一个 IX 锁。
意向锁是表级锁，它们的提出仅仅为了在之后加表级别的 S 锁和 X 锁时可以快速判断表中的记录是否被上锁，以避免用遍历的方式来查看表中有没有上锁的记录。就是说其实 IS 锁和 IS 锁是兼容的，IX 锁和 IX 锁是兼容的。
为什么需要意向锁？
InnoDB 的意向锁主要用户多粒度的锁并存的情况。比如事务A要在一个表上加S锁，如果表中的一行已被事务 B 加了 X 锁，那么该锁的申请也应被阻塞。如果表中的数据很多，逐行检查锁标志的开销将很大，系统的性能将会受到影响。
举个例子，如果表中记录 1 亿，事务 A 把其中有几条记录上了行锁了，这时事务 B 需要给这个表加表级锁，如果没有意向锁的话，那就要去表中查找这一亿条记录是否上锁了。如果存在意向锁，那么假如事务Ａ在更新一条记录之前，先加意向锁，再加Ｘ锁，事务 B 先检查该表上是否存在意向锁，存在的意向锁是否与自己准备加的锁冲突，如果有冲突，则等待直到事务Ａ释放，而无须逐条记录去检测。事务B在更新表时无需确切知道哪一行被锁定，只需要知道至少有一行已被锁定即可。
说白了意向锁的主要作用是处理行锁和表锁之间的矛盾，能够显示某个事务正在某一行上持有了锁，或者准备去持有锁。
表级别的各种锁的兼容性：
| S | IS | X | IX | |
|---|---|---|---|---|
| S | 兼容 | 兼容 | 不兼容 | 不兼容 |
| IS | 兼容 | 兼容 | 不兼容 | 不兼容 |
| X | 不兼容 | 不兼容 | 不兼容 | 不兼容 |
| IS | 兼容 | 兼容 | 不兼容 | 不兼容 |
对于 MySQL 的读操作，有两种方式加锁。
1️⃣ SELECT * FROM table LOCK IN SHARE MODE
如果当前事务执行了该语句，那么它会为读取到的记录加 S 锁，这样允许别的事务继续获取这些记录的 S 锁（比方说别的事务也使用 SELECT ... LOCK IN SHARE MODE 语句来读取这些记录），但是不能获取这些记录的 X 锁（比方说使用 SELECT ... FOR UPDATE 语句来读取这些记录，或者直接修改这些记录）。
如果别的事务想要获取这些记录的 X 锁，那么它们会阻塞，直到当前事务提交之后将这些记录上的 S 锁释放掉
2️⃣ SELECT FROM table FOR UPDATE
如果当前事务执行了该语句，那么它会为读取到的记录加 X 锁，这样既不允许别的事务获取这些记录的 S 锁（比方说别的事务使用 SELECT ... LOCK IN SHARE MODE 语句来读取这些记录），也不允许获取这些记录的 X 锁（比如说使用 SELECT ... FOR UPDATE 语句来读取这些记录，或者直接修改这些记录）。
如果别的事务想要获取这些记录的 S 锁或者 X 锁，那么它们会阻塞，直到当前事务提交之后将这些记录上的 X 锁释放掉。
DELETE、UPDATE、INSERT是MySQL中常见的写入操作。隐式上锁，自动加锁，解锁。
1️⃣ DELETE
对一条记录做 DELETE 操作的过程其实是先在 B+树中定位到这条记录的位置，然后获取一下这条记录的 X 锁，然后再执行 delete mark 操作。我们也可以将这个过程理解为采用获取X锁的锁定读方式来定位待删除记录在B+树中的位置。
2️⃣ INSERT
一般情况下，新插入一条记录的操作并不加锁，InnoDB 通过一种称之为隐式锁来保护这条新插入的记录在本事务提交前不被别的事务访问。
3️⃣ UPDATE
在对一条记录做 UPDATE 操作时分为三种情况：
① 如果未修改该记录的键值并且被更新的列占用的存储空间在修改前后未发生变化，则先在 B+树中定位到这条记录的位置，然后再获取一下记录的 X 锁，最后在原记录的位置进行修改操作。我们也可以将将在 B+树中记录待修改位置的过程视为获取 X 锁的锁定读操作。
② 如果未修改该记录的键值并且至少有一个被更新的列占用的存储空间在修改前后发生变化，则先在 B+树中定位到这条记录的位置，然后获取一下记录的 X 锁，将该记录彻底删除掉（就是把记录彻底移入垃圾链表），最后再插入一条新记录。这个定位待修改记录在 B+树中位置的过程看成是一个获取 X 锁的锁定读，新插入的记录由 INSERT 操作提供的隐式锁进行保护。
③ 如果修改了该记录的键值，则相当于在原记录上做 DELETE 操作之后再来一次 INSERT 操作，加锁操作就需要按照 DELETE 和 INSERT 的规则进行了。
PS：为什么上了写锁，别的事务还可以读操作？
因为InnoDB有 MVCC机制（多版本并发控制），可以使用快照读，而不会被阻塞。
什么是锁的粒度？所谓锁的粒度就是你要锁住的范围是多大。
比如你在家上卫生间，你只要锁住卫生间就可以了，不需要将整个家都锁起来不让家人进门吧，卫生间就是你的加锁粒度。
怎样才算合理的加锁粒度呢？
其实卫生间并不只是用来上厕所的，还可以洗澡，洗手。这里就涉及到优化加锁粒度的问题。
你在卫生间里洗澡，其实别人也可以同时去里面洗手，只要做到隔离起来就可以，如果马桶，浴缸，洗漱台都是隔开相对独立的（干湿分离了属于是），实际上卫生间可以同时给三个人使用，当然三个人做的事儿不能一样。这样就将锁的粒度细化了，你在洗澡时只需将浴室门关上，他人仍然可以进去洗手。若在设计卫生间时未将不同的功能区域分隔开，则无法最大化利用卫生间资源。
同样，在 MySQL 中也存在锁的粒度。通常分为三种，行锁，表锁和页锁。
在共享锁和独占锁的介绍中其实都是针对某一行记录的，所以也可以称之为行锁。
对一条记录加锁影响的也只是这条记录而已，所以行锁的锁定粒度在 MySQL 中是最细的。InnoDB 存储引擎默认锁就是行锁。
它具有以下特点：
锁冲突概率最低，并发性高
由于行锁的粒度小，所以发生锁定资源争用的概率也最小，从而锁冲突的概率就低，并发性越高。
开销大，加锁慢
锁是非常消耗性能的，试想一下，如果对数据库的多条数据加锁，必然会占用很多资源，而对于加锁需要等待之前的锁释放才能加锁。
会产生死锁
关于什么是死锁，可以往下看。
表级锁为表级别的锁定，会锁定整张表，可以很好的避免死锁，也是 MySQL 中最大颗粒度的锁定机制。
MyISAM 存储引擎的默认锁就是表锁。
它具有以下特点：
开销小，加锁快
由于是对整张表加锁，速度必然快于单条数据加锁。
不会产生死锁
都对整张表加锁了，其他事务根本拿不到锁，自然也不会产生死锁。
锁粒度大，发生锁冲突概率大，并发性低
页级锁是 MySQL 中比较独特的一种锁定级别，在其他数据库管理软件中并不常见。
页级锁的颗粒度介于行级锁与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处理能力同样也是介于上面二者之间。另外，页级锁和行级锁一样，会发生死锁。
| 行锁 | 表锁 | 页锁 | |
|---|---|---|---|
| 锁的粒度 | 小 | 大 | 两者之间 |
| 加锁效率 | 慢 | 快 | 两者之间 |
| 冲突概率 | 低 | 高 | - |
| 并发性能 | 高 | 低 | 一般 |
| 性能开销 | 大 | 小 | 两者之间 |
| 是否死锁 | 是 | 否 | 是 |
对于上面的锁的介绍，我们实际上可以知道，主要区分就是在锁的粒度上面，而 InnoDB 中用的锁就是行锁，也叫记录锁，但是要注意，这个记录指的是通过给索引上的索引项加锁。
InnoDB 这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB 才使用行级锁，否则，InnoDB 将使用表锁。
不论是使用主键索引、唯一索引或普通索引，InnoDB 都会使用行锁来对数据加锁。
只有执行计划真正使用了索引，才能使用行锁：即便在条件中使用了索引字段，但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价来决 定的，如果 MySQL 认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB 将使用表锁，而不是行锁。
同时当我们用范围条件而不是相等条件检索数据，并请求锁时，InnoDB 会给符合条件的已有数据记录的索引项加锁。
不过即使是行锁，InnoDB 里也是分成了各种类型的。换言之，即使对同一条记录加上行锁，不同的锁类型也会产生不同的效果。通常有以下几种常用的行锁类型。
记录锁，单条索引记录上加锁。
Record Lock 锁住的永远是索引，不包括记录本身，即使该表上没有任何索引，那么innodb会在后台创建一个隐藏的聚集主键索引，那么锁住的就是这个隐藏的聚集主键索引。
记录锁是有 S 锁和 X 锁之分的，当一个事务获取了一条记录的 S 型记录锁后，其他事务也可以继续获取该记录的 S 型记录锁，但不可以继续获取 X 型记录锁；当一个事务获取了一条记录的 X 型记录锁后，其他事务既不可以继续获取该记录的 S 型记录锁，也不可以继续获取 X 型记录锁。
间隙锁，对索引前后的间隙上锁，不对索引本身上锁。
MySQL 在 REPEATABLE READ 隔离级别下是可以解决幻读问题的，解决方案有两种，可以使用 MVCC 方案解决，也可以采用加锁方案解决。但是在使用加锁方案解决时有问题，就是事务在第一次执行读取操作时，那些幻影记录尚 不存在，我们无法给这些幻影记录加上记录锁。所以我们可以使用间隙锁对其上锁。
如存在这样一张表：
CREATE TABLE test (
id INT (1) NOT NULL AUTO_INCREMENT,
number INT (1) NOT NULL COMMENT '数字',
PRIMARY KEY (id),
KEY number (number) USING BTREE
) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8;
# 插入以下数据
INSERT INTO test VALUES (1, 1);
INSERT INTO test VALUES (5, 3);
INSERT INTO test VALUES (7, 8);
INSERT INTO test VALUES (11, 12);如下：
开启一个事务 A：
BEGIN; SELECT * FROM test WHERE number = 3 FOR UPDATE;
此时，会对((1,1),(5,3))和((5,3),(7,8))之间上锁。
如果此时在开启一个事务 B 进行插入数据，如下：
BEGIN; # 阻塞 INSERT INTO test (id, number) VALUES (2,2);
结果如下：
为什么不能插入？因为记录(2,2)要 插入的话，在索引 number上，刚好落在((1,1),(5,3))和((5,3),(7,8))之间，是有锁的，所以不允许插入。 如果在范围外，当然是可以插入的，如：
INSERT INTO test (id, number) VALUES (8,8);
next-key locks 是索引记录上的记录锁和索引记录之前的间隙上的间隙锁的组合，包括记录本身，每个 next-key locks 是前开后闭区间，也就是说间隙锁只是锁的间隙，没有锁住记录行，next-key locks 就是间隙锁基础上锁住右边界行。
InnoDB 默认使用 REPEATABLE READ 隔离级别。在这种情况下，InnoDB 使用 Next-Key Locks 锁进行搜索和索引扫描，这可以防止幻读的发生。
乐观锁和悲观锁其实不算是具体的锁，而是一种锁的思想，不仅仅是在 MySQL 中体现，常见的 Redis 等中间件都可以应用这种思想。
所谓乐观锁，就是持有乐观的态度，当我们更新一条记录时，假设这段时间没有其他人来操作这条数据。
实现乐观锁常见的方式
常见的实现方式就是在表中添加 version字段，控制版本号，每次修改数据后+1。
在每次更新数据之前，先查询出该条数据的 version版本号，再执行业务操作，然后在更新数据之前在把查到的版本号和当前数据库中的版本号作对比，若相同，则说明没有其他线程修改过该数据，否则作相应的异常处理。
所谓悲观锁，就是持有悲观的态度，一开始就假设改数据会被别人修改。
悲观锁的实现方式有两种
共享锁（读锁）和排它锁（写锁），参考上面。
是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统 处于死锁状态或系统产生了死锁。
产生的条件
互斥条件：一个资源每次只能被一个进程使用；
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放；
不剥夺条件：进程已获得的资源，在没有使用完之前，不能强行剥夺；
循环等待条件：多个进程之间形成的一种互相循环等待的资源的关系。
MySQL 中其实也是一样的，如下还是这样一张表：
CREATE TABLE `user` ( `id` bigint NOT NULL COMMENT '主键', `name` varchar(20) DEFAULT NULL COMMENT '姓名', `sex` char(1) DEFAULT NULL COMMENT '性别', `age` varchar(10) DEFAULT NULL COMMENT '年龄', `url` varchar(40) DEFAULT NULL, PRIMARY KEY (`id`), KEY `suf_index_url` (`name`(3)) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3; # 数据 INSERT INTO `user` (`id`, `name`, `sex`, `age`, `url`) VALUES ('1', 'a', '1', '18', 'https://javatv.net'); INSERT INTO `user` (`id`, `name`, `sex`, `age`, `url`) VALUES ('2', 'b', '1', '18', 'https://javatv.net');
按照如下顺序执行：
| A | B | |
|---|---|---|
| ① | BEGIN | |
| ② | BEGIN | |
| ③ | SELECT * FROM user WHERE name='a' FOR UPDATE |
|
| ④ | SELECT * FROM user WHERE name='b' FOR UPDATE |
|
| ⑤ | SELECT * FROM user WHERE name='b' FOR UPDATE |
|
| ⑥ | SELECT * FROM user WHERE name='a' FOR UPDATE |
1、开启 A、B 两个事务；
2、首先 A 先查询name='a'的数据，然后 B 也查询name='b'的数据；
3、在 B 没释放锁的情况下，A 尝试对 name='b'的数据加锁，此时会阻塞；
4、若此时，事务 B 在没释放锁的情况下尝试对 name='a'的数据加锁，则产生死锁。
此时，MySQL 检测到了死锁，并结束了 B 中事务的执行，此时，切回事务 A，发现原本阻塞的 SQL 语句执行完成了。可通过show engine innodb status \G查看死锁。
如何避免
从上面的案例可以看出，死锁的关键在于：两个(或以上)的 Session 加锁的顺序不一致，所以我们在执行 SQL 操作的时候要让加锁顺序一致，尽可能一次性锁定所需的数据行。
以上是MySQL锁及分类有哪些的详细内容。更多信息请关注PHP中文网其他相关文章！
