文章很长，建议收藏起来慢慢读！疯狂创客圈总目录 语雀版 | 总目录 码云版| 总目录 博客园版 为您奉上珍贵的学习资源 ：
免费赠送 经典图书:《Java高并发核心编程（卷1）》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷2）》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Netty Zookeeper Redis 高并发实战》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《SpringCloud Nginx高并发核心编程》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 资源宝库： Java 必备 百度网盘资源大合集 价值>10000元 加尼恩领取
| 入大厂 、做架构、大力提升Java 内功 必备的精彩博文 | 2021 秋招涨薪1W + 必备的精彩博文 |
|---|---|
| 1：Redis 分布式锁 （图解-秒懂-史上最全） | 2：Zookeeper 分布式锁 （图解-秒懂-史上最全） |
| 3: Redis与MySQL双写一致性如何保证？ （面试必备） | 4: 面试必备：秒杀超卖 解决方案 （史上最全） |
| 5:面试必备之：Reactor模式 | 6: 10分钟看懂， Java NIO 底层原理 |
| 7:TCP/IP（图解+秒懂+史上最全） | 8：Feign原理 （图解） |
| 9:DNS图解（秒懂 + 史上最全 + 高薪必备） | 10：CDN图解（秒懂 + 史上最全 + 高薪必备） |
| 10: 分布式事务（ 图解 + 史上最全 + 吐血推荐 ） |
| Java 面试题 30个专题 , 史上最全 , 面试必刷 | 阿里、京东、美团... 随意挑、横着走！！！ |
|---|---|
| 1： JVM面试题（史上最强、持续更新、吐血推荐） | 2：Java基础面试题（史上最全、持续更新、吐血推荐 |
| 3：架构设计面试题 （史上最全、持续更新、吐血推荐） | 4：设计模式面试题 （史上最全、持续更新、吐血推荐） |
| 17、分布式事务面试题 （史上最全、持续更新、吐血推荐） | 一致性协议 （史上最全） |
| 29、多线程面试题（史上最全） | 30、HR面经，过五关斩六将后，小心阴沟翻船！ |
| 9.网络协议面试题（史上最全、持续更新、吐血推荐） | 更多专题， 请参见【 疯狂创客圈 高并发 总目录 】 |
| SpringCloud 精彩博文 | |
|---|---|
| nacos 实战（史上最全） | sentinel （史上最全+入门教程） |
| SpringCloud gateway （史上最全） | 更多专题， 请参见【 疯狂创客圈 高并发 总目录 】 |
先来就库存超卖的问题作描述：一般电子商务网站都会遇到如团购、秒杀、特价之类的活动，而这样的活动有一个共同的特点就是访问量激增、上千甚至上万人抢购一个商品。然而，作为活动商品，库存肯定是很有限的，如何控制库存不让出现超买，以防止造成不必要的损失是众多电子商务网站程序员头疼的问题，这同时也是最基本的问题。
在秒杀系统设计中，超卖是一个经典、常见的问题，任何商品都会有数量上限，如何避免成功下订单买到商品的人数不超过商品数量的上限，这是每个抢购活动都要面临的难点。
在多个用户同时发起对同一个商品的下单请求时，先查询商品库存，再修改商品库存，会出现资源竞争问题，导致库存的最终结果出现异常。问题：
当商品A一共有库存15件，用户甲先下单10件，用户乙下单8件，这时候库存只能满足一个人下单成功，如果两个人同时提交，就出现了超卖的问题。
通过悲观锁解决超卖
通过乐观锁解决超卖
通过分段执行的排队方案解决超卖
当查询某条记录时，即让数据库为该记录加锁，锁住记录后别人无法操作，使用类似如下语法：
beginTranse(开启事务) try{ query('select amount from s_store where goodID = 12345'); if(库存 > 0){ //quantity为请求减掉的库存数量 query('update s_store set amount = amount - quantity where goodID = 12345'); } }catch( Exception e ){ rollBack(回滚) } commit(提交事务)
问题：
注意，上面的代码容易出现死锁，采用不多。
有社群小伙伴，对死锁的的原因比较关心，这里简单分析一下。
上面的语句，可能出现死锁的简单的原因，在事务的隔离级别为Serializable时，假设事务t1通过 select拿到了共享锁，而其他事务如果拿到了 排他锁，此时t1 去拿排他锁的时候， 就有可能会出现死锁,注意，这里是可能，并不是一定。实际的原因，与事务的隔离级别和语句的复杂度，都有关系。
总之，避免死锁的方式之一（稍后介绍）：为了在单个 InnoDB 表上执行多个并发写入操作时避免死锁，可以在事务开始时通过为预期要修改的每个元祖（行）使用 SELECT … FOR UPDATE 语句来获取必要的锁，即使这些行的更改语句是在之后才执行的。
解决方案：一般提前采用 select for update，提前加上写锁。
beginTranse(开启事务) try{ query('select amount from s_store where goodID = 12345 for update'); if(库存 > 0){ //quantity为请求减掉的库存数量 query('update s_store set amount = amount - quantity where goodID = 12345'); } }catch( Exception e ){ rollBack(回滚) } commit(提交事务)
行锁：分为 共享锁 和 排它锁。
共享锁又称：读锁。当一个事务对某几行上读锁时，允许其他事务对这几行进行读操作，但不允许其进行写操作，也不允许其他事务给这几行上排它锁，但允许上读锁。
上共享锁的写法：lock in share mode
例如： select math from zje where math>60 lock in share mode；
排它锁又称：写锁。当一个事务对某几个上写锁时，不允许其他事务写，但允许读。更不允许其他事务给这几行上任何锁。包括写锁。
上排它锁的写法：for update
例如：select math from zje where math >60 for update；
死锁
死锁：例如说两个事务，事务A锁住了15行，同时事务B锁住了610行，此时事务A请求锁住610行，就会阻塞直到事务B施放610行的锁，而随后事务B又请求锁住15行，事务B也阻塞直到事务A释放15行的锁。死锁发生时，会产生Deadlock错误。
表锁：不会出现死锁，发生锁冲突几率高，并发低。
表锁是对表操作的，所以自然锁住全表的表锁就不会出现死锁。但是表锁效率低。
行锁：会出现死锁，发生锁冲突几率低，并发高。
3.行锁的要点
注意几点：
1.行锁必须有索引才能实现，否则会自动锁全表，那么就不是行锁了。
2.两个事务不能锁同一个索引，例如：
事务A先执行： select math from zje where math>60 for update; 事务B再执行： select math from zje where math<60 for update； 这样的话，事务B是会阻塞的。如果事务B把 math索引换成其他索引就不会阻塞， 但注意，换成其他索引锁住的行不能和math索引锁住的行有重复。
3.insert ，delete ， update在事务中都会自动默认加上排它锁。
实现：
| 会话1： | 会话2： |
|---|---|
| begin； select math from zje where math>60 for update； |
begin； update zje set math=99 where math=68； 阻塞 |
MyISAM：MyISAM是默认存储引擎（Mysql5.1前），每个MyISAM在磁盘上存储成三个文件，每一个文件的名字均以表的名字开始，扩展名指出文件类型。
.frm文件存储表定义
·MYD (MYData)文件存储表的数据
.MYI (MYIndex)文件存储表的索引
InnoDB：MySQL的默认存储引擎，给 MySQL 提供了具有事务(transaction)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)、多版本并发控制(multi-versioned concurrency control)的事务安全(transaction-safe (ACID compliant))型表。InnoDB 提供了行级锁(locking on row level)，提供与 Oracle 类似的不加锁读取(non-locking read in SELECTs)。
MyISAM与InnoDB 的区别
InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；
InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；
聚集索引 VS 非聚集索引
InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。
InnoDB的B+树主键索引的叶子节点就是数据文件，辅助索引的叶子节点是主键的值
but, MyISAM是非聚集索引，也是使用B+Tree作为索引结构，索引和数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。
总结
也就是说：InnoDB的B+树主键索引的叶子节点就是数据文件，辅助索引的叶子节点是主键的值；而MyISAM的B+树主键索引和辅助索引的叶子节点都是数据文件的地址指针。
那么为什么InnoDB没有了这个变量呢？
因为InnoDB的事务特性，在同一时刻表中的行数对于不同的事务而言是不一样的，因此count统计会计算对于当前事务而言可以统计到的行数，而不是将总行数储存起来方便快速查询。InnoDB会尝试遍历一个尽可能小的索引除非优化器提示使用别的索引。如果二级索引不存在，InnoDB还会尝试去遍历其他聚簇索引。
如果索引并没有完全处于InnoDB维护的缓冲区（Buffer Pool）中，count操作会比较费时。可以建立一个记录总行数的表并让你的程序在INSERT/DELETE时更新对应的数据。和上面提到的问题一样，如果此时存在多个事务的话这种方案也不太好用。如果得到大致的行数值已经足够满足需求可以尝试SHOW TABLE STATUS
Innodb不支持全文索引，而MyISAM支持全文索引，在涉及全文索引领域的查询效率上MyISAM速度更快高；PS：5.7以后的InnoDB支持全文索引了
MyISAM表格可以被压缩后进行查询操作
InnoDB支持表、行(默认)级锁，而MyISAM支持表级锁
InnoDB的行锁是实现在索引上的，而不是锁在物理行记录上。潜台词是，如果访问没有命中索引，也无法使用行锁，将要退化为表锁。
例如： t_user(uid, uname, age, sex) innodb; uid PK 无其他索引 update t_user set age=10 where uid=1; 命中索引，行锁。 update t_user set age=10 where uid != 1; 未命中索引，表锁。 update t_user set age=10 where name='chackca'; 无索引，表锁。
8、InnoDB表必须有唯一索引（如主键）（用户没有指定的话会自己找/生产一个隐藏列Row_id来充当默认主键），而Myisam可以没有
9、Innodb存储文件有frm、ibd，而Myisam是frm、MYD、MYI
Innodb：frm是表定义文件，ibd是数据文件
Myisam：frm是表定义文件，myd是数据文件，myi是索引文件
如何选择：
1. 是否要支持事务，如果要请选择innodb，如果不需要可以考虑MyISAM；
2. 如果表中绝大多数都只是读查询，可以考虑MyISAM，如果既有读也有写，请使用InnoDB。
3. 系统奔溃后，MyISAM恢复起来更困难，能否接受；
4. MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不会差。
InnoDB为什么推荐使用自增ID作为主键？
答：自增ID可以保证每次插入时B+索引是从右边扩展的，可以避免B+树和频繁合并和分裂（对比使用UUID）。如果使用字符串主键和随机主键，会使得数据随机插入，效率比较差。
innodb引擎的4大特性
插入缓冲（insert buffer),二次写(double write),自适应哈希索引(ahi),预读(read ahead)
在MySQL的InnoDB中，预设的Tansaction isolation level 为REPEATABLE READ(可重读)
在SELECT 的读取锁定主要分为两种方式：
SELECT ... LOCK IN SHARE MODE
SELECT ... FOR UPDATE
这两种方式在事务(Transaction) 进行当中SELECT 到同一个数据表时，都必须等待其它事务数据被提交(Commit)后才会执行。
而主要的不同在于共享锁(lock in share mode) 在有一方事务要Update 同一个表单时很容易造成死锁。
简单的说，如果SELECT 后面若要UPDATE 同一个表单，最好使用SELECT ... UPDATE。
MySQL SELECT ... FOR UPDATE 的Row Lock 与Table Lock
上面介绍过SELECT ... FOR UPDATE 的用法，不过锁定(Lock)的数据是判别就得要注意一下了。由于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;
例2: (明确指定主键，若查无此数据，无lock)
SELECT * FROM products WHERE id='-1' FOR UPDATE;
例2: (无主键，table lock)
SELECT * FROM products WHERE name='Mouse' FOR UPDATE;
例3: (主键不明确，table lock)
SELECT * FROM products WHERE id<>'3' FOR UPDATE;
例4: (主键不明确，table lock)
SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;
那么后端的数据库在高并发和超卖下会遇到什么问题呢？主要会有如下3个问题：（主要讨论写的问题，读的问题通过增加cache可以很容易的解决）
I： 首先MySQL自身对于高并发的处理性能就会出现问题，一般来说，MySQL的处理性能会随着并发thread上升而上升，但是到了一定的并发度之后会出现明显的拐点，之后一路下降，最终甚至会比单thread的性能还要差。
II： 其次，超卖的根结在于减库存操作是一个事务操作，需要先select，然后insert，最后update -1。最后这个-1操作是不能出现负数的，但是当多用户在有库存的情况下并发操作，出现负数这是无法避免的。
III：最后，当减库存和高并发碰到一起的时候，由于操作的库存数目在同一行，就会出现争抢InnoDB行锁的问题，导致出现互相等待甚至死锁，从而大大降低MySQL的处理性能，最终导致前端页面出现超时异常。
针对上述问题，如何解决呢？ 我们先看眼淘宝的高大上解决方案：
I： 关闭死锁检测，提高并发处理性能。
在一个高并发的MySQL服务器上，事务会递归检测死锁，当超过一定的深度时，性能的下降会变的不可接受。FACEBOOK早就提出了禁止死锁检测。
我们做了一个实验，在禁止死锁检测后，TPS得到了极大的提升，如下图所示：
禁止死锁检测后，即使死锁发生，也不会回滚事务，而是全部等待到超时
Mysql 的 innobase_deadlock_check是在innodb里新加的系统变量，用于控制是否打开死锁检测
死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,可以认为如果一个资源被锁定，它总会在以后某个时间被释放。而死锁发生在当多个进程访问同一数据库时，其中每个进程拥有的锁都是其他进程所需的，由此造成每个进程都无法继续下去。
InnoDB的并发写操作会触发死锁，InnoDB也提供了死锁检测机制，可以通过设置innodb_deadlock_detect参数可以打开或关闭死锁检测:
innodb_deadlock_detect = on 打开死锁检测，数据库发生死锁时自动回滚（默认选项）
innodb_deadlock_detect = off 关闭死锁检测，发生死锁的时候，用锁超时来处理，通过设置锁超时参数innodb_lock_wait_timeout 可以在超时发生时回滚被阻塞的事务
设置mysql 事务锁超时时间 innodb_lock_wait_timeout
Mysql数据库采用InnoDB模式，默认参数:innodb_lock_wait_timeout设置锁等待的时间是50s，一旦数据库锁超过这个时间就会报错。
mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait_timeout';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 50 |
+--------------------------+-------+
1 row in set (0.00 sec)
mysql> SET GLOBAL innodb_lock_wait_timeout=120;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait_timeout';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 120 |
+--------------------------+-------+
1 row in set (0.00 sec)
mysql>
设置InnoDB Monitors方法
还可以通过设置InnDB Monitors来进一步观察锁冲突详细信息
建立test库
mysql>create database test; Query OK, 1 row affected (0.20 sec) mysql> use test Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> create table innodb_monitor(a INT) engine=innodb; Query OK, 0 rows affected (1.04 sec) mysql> create table innodb_tablespace_monitor(a INT) engine=innodb; Query OK, 0 rows affected (0.70 sec) mysql> create table innodb_lock_monitor(a INT) engine=innodb; Query OK, 0 rows affected (0.36 sec) mysql> create table innodb_table_monitor(a INT) engine=innodb; Query OK, 0 rows affected (0.08 sec)
可以通过show engine innodb status命令查看死锁信息
mysql> show engine innodb status \G *************************** 1. row *************************** Type: InnoDB Name: Status: ===================================== 2018-05-10 09:17:10 0x7f1fbc21a700 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 46 seconds ----------------- BACKGROUND THREAD ----------------- srv_master_thread loops: 53 srv_active, 0 srv_shutdown, 240099 srv_idle srv_master_thread log flush and writes: 0 ---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 2007 OS WAIT ARRAY INFO: signal count 1987 RW-shared spins 3878, rounds 5594, OS waits 1735 RW-excl spins 3, rounds 91, OS waits 4 RW-sx spins 1, rounds 30, OS waits 1 Spin rounds per wait: 1.44 RW-shared, 30.33 RW-excl, 30.00 RW-sx ------------ TRANSACTIONS ------------ Trx id counter 78405 Purge done for trx's n:o < 78404 undo n:o < 10 state: running but idle History list length 21 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 421249967052640, not started 0 lock struct(s), heap size 1136, 0 row lock(s) -------- FILE I/O -------- I/O thread 0 state: waiting for completed aio requests (insert buffer thread) I/O thread 1 state: waiting for completed aio requests (log thread) I/O thread 2 state: waiting for completed aio requests (read thread) ............................................................................. ............................................................................. .............................................................................
II：请求排队
修改源代码，将排队提到进入引擎层前，降低引擎层面的并发度。
如果请求一股脑的涌入数据库，势必会由于争抢资源造成性能下降，通过排队，让请求从混沌到有序，从而避免数据库在协调大量请求时过载。
请求排队：如果请求一股脑的涌入数据库，势必会由于争抢资源造成性能下降，通过排队，让请求从混沌到有序，从而避免数据库在协调大量请求时过载。
III：请求合并（组提交）
请求合并（组提交），降低server和引擎的交互次数，降低IO消耗。
甲买了一个商品，乙也买了同一个商品，与其把甲乙当做当做单独的请求分别执行一次商品库存减一的操作，不如把他们合并后统一执行一次商品库存减二的操作，请求合并的越多，效率提升的就越大。
实操建议
不过结合我们的实际，死锁监测可以关闭，但是，改mysql源码这种高大上的解决方案显然有那么一点不切实际。
考虑到行级锁定均由各个存储引擎自行实现，而且具体实现也各有差别，而InnoDB是目前事务型存储引擎中使用最为广泛的存储引擎，所以这里我们就主要分析一下InnoDB的锁定特性。
总的来说，InnoDB的锁定机制和Oracle数据库有不少相似之处。InnoDB的行级锁定同样分为两种类型，共享锁和排他锁，而在锁定机制的实现过程中为了让行级锁定和表级锁定共存，InnoDB也同样使用了意向锁（表级锁定）的概念，也就有了意向共享锁和意向排他锁这两种。
当一个事务需要给自己需要的某个资源加锁的时候，如果遇到一个共享锁正锁定着自己需要的资源的时候，自己可以再加一个共享锁，不过不能加排他锁。但是，如果遇到自己需要锁定的资源已经被一个排他锁占有之后，则只能等待该锁定释放资源之后自己才能获取锁定资源并添加自己的锁定。而意向锁的作用就是当一个事务在需要获取资源锁定的时候，如果遇到自己需要的资源已经被排他锁占用的时候，该事务可以需要锁定行的表上面添加一个合适的意向锁。如果自己需要一个共享锁，那么就在表上面添加一个意向共享锁。而如果自己需要的是某行（或者某些行）上面添加一个排他锁的话，则先在表上面添加一个意向排他锁。意向共享锁可以同时并存多个，但是意向排他锁同时只能有一个存在。
InnoDB的锁定模式实际上可以分为四种：共享锁（S），排他锁（X），意向共享锁（IS）和意向排他锁（IX），我们可以通过以下表格来总结上面这四种所的共存逻辑关系：
如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。
意向锁是InnoDB自动加的，不需用户干预。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁；事务可以通过以下语句显示给记录集加共享锁或排他锁。
共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 排他锁（X)：SELECT * FROM table_name WHERE ... FOR UPDATE
用SELECT ... IN SHARE MODE获得共享锁，主要用在需要数据依存关系时来确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。
但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT... FOR UPDATE方式获得排他锁。
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；
对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。
例：
假如emp表中只有101条记录，其empid的值分别是 1,2,...,100,101，下面的SQL：
mysql> select * from emp where empid > 100 for update;
是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。
InnoDB使用间隙锁的目的：
（1）防止幻读，以满足相关隔离级别的要求。对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；
（2）为了满足其恢复和复制的需要。
很显然，在使用范围条件检索并锁定记录时，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害。
除了间隙锁给InnoDB带来性能的负面影响之外，通过索引实现锁定的方式还存在其他几个较大的性能隐患：
（1）当Query无法利用索引的时候，InnoDB会放弃使用行级别锁定而改用表级别的锁定，造成并发性能的降低；
（2）当Query使用的索引并不包含所有过滤条件的时候，数据检索使用到的索引键所只想的数据可能有部分并不属于该Query的结果集的行列，但是也会被锁定，因为间隙锁锁定的是一个范围，而不是具体的索引键；
（3）当Query在使用索引定位数据的时候，如果使用的索引键一样但访问的数据行不同的时候（索引只是过滤条件的一部分），一样会被锁定。
因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。
还要特别说明的是，InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁。
并发事务可能造成：脏读、不可重复读和幻读等问题 ，这些问题其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决，解决方案如下：
MVCC 全称是多版本并发控制系统，InnoDB 和 Falcon 存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决幻读问题。
MVCC 是怎么工作的？
InnoDB 的 MVCC 是通过在每行记录后面保存两个隐藏的列来实现，这两个列一个保存了行的创建时间，一个保存行的过期时间（删除时间）。当然存储的并不是真实的时间而是系统版本号（system version number）。每开始一个新的事务，系统版本号都会自动新增，事务开始时刻的系统版本号会作为事务的版本号，用来查询到每行记录的版本号进行比较。
REPEATABLE READ（可重读）隔离级别下 MVCC 如何工作？
快照读和当前读
在mysql中select分为快照读和当前读，执行下面的语句
select * from table where id = ?;
执行的是快照读，读的是数据库记录的快照版本，是不加锁的。（这种说法在隔离级别为Serializable中不成立）
下面六句Sql的区别呢
select * from table where id = ?
select * from table where id < ?
select * from table where id = ? lock in share mode
select * from table where id < ? lock in share mode
select * from table where id = ? for update
select * from table where id < ? for update
在不同的事务隔离级别下，是否加锁，加的是共享锁还是排他锁，是否存在间隙锁，您能说出来嘛？
要回答这个问题，先问自己三个问题
关于mysql的索引，啰嗦一下：
锁类型
意向锁存在的目的?
这里说一下意向锁存在的目的。假设事务T1，用X锁来锁住了表上的几条记录，那么此时表上存在IX锁，即意向排他锁。那么此时事务T2要进行LOCK TABLE … WRITE的表级别锁的请求，可以直接根据意向锁是否存在而判断是否有锁冲突。
这里我对官网补充一下，隔离级别比Read Committed低的情况下，也不会使用间隙锁，如隔离级别为Read Uncommited时，也不存在间隙锁。当隔离级别为Repeatable Read和Serializable时，就会存在间隙锁。
(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)
索引原理介绍
先来一张带主键的表，如下所示，pId是主键
| pId | name | birthday |
|---|---|---|
| 5 | zhangsan | 2016-10-02 |
| 8 | lisi | 2015-10-04 |
| 11 | wangwu | 2016-09-02 |
| 13 | zhaoliu | 2015-10-07 |
画出该表的结构图如下
如上图所示，分为上下两个部分，上半部分是由主键形成的B+树，下半部分就是磁盘上真实的数据！那么，当我们， 执行下面的语句
select * from table where pId='11'
那么，执行过程如下
如上图所示，从根开始，经过3次查找，就可以找到真实数据。如果不使用索引，那就要在磁盘上，进行逐行扫描，直到找到数据位置。显然，使用索引速度会快。但是在写入数据的时候，需要维护这颗B+树的结构，因此写入性能会下降！
聚簇索引、非聚簇索引
聚簇索引：将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据
非聚簇索引：将数据与索引分开存储，索引结构的叶子节点指向了数据对应的位置
在innodb中，在聚簇索引之上创建的索引称之为辅助索引，非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引。辅助索引叶子节点存储的不再是行的物理位置，而是主键值，辅助索引访问数据总是需要二次查找。
聚簇索引具有唯一性，由于聚簇索引是将数据跟索引结构放到一块，因此一个表仅有一个聚簇索引。
表中行的物理顺序和索引中行的物理顺序是相同的，在创建任何非聚簇索引之前创建聚簇索引，这是因为聚簇索引改变了表中行的物理顺序，数据行 按照一定的顺序排列，并且自动维护这个顺序；
聚簇索引默认是主键，如果表中没有定义主键，InnoDB 会选择一个唯一且非空的索引代替。如果没有这样的索引，InnoDB 会隐式定义一个主键（类似oracle中的RowId）来作为聚簇索引。如果已经设置了主键为聚簇索引又希望再单独设置聚簇索引，必须先删除主键，然后添加我们想要的聚簇索引，最后恢复设置主键即可。
MyISAM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。
使用聚簇索引的优势：
每次使用辅助索引检索都要经过两次B+树查找，看上去聚簇索引的效率明显要低于非聚簇索引，这不是多此一举吗？聚簇索引的优势在哪？
1.由于行数据和聚簇索引的叶子节点存储在一起，同一页中会有多条行数据，访问同一数据页不同行记录时，已经把页加载到了Buffer中（缓存器），再次访问时，会在内存中完成访问，不必访问磁盘。这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键Id来组织数据，获得数据更快。
2.辅助索引的叶子节点，存储主键值，而不是数据的存放地址。好处是当行数据放生变化时，索引树的节点也需要分裂变化；或者是我们需要查找的数据，在上一次IO读写的缓存中没有，需要发生一次新的IO操作时，可以避免对辅助索引的维护工作，只需要维护聚簇索引树就好了。另一个好处是，因为辅助索引存放的是主键值，减少了辅助索引占用的存储空间大小。
注：我们知道一次io读写，可以获取到16K大小的资源，我们称之为读取到的数据区域为Page。而我们的B树，B+树的索引结构，叶子节点上存放好多个关键字（索引值）和对应的数据，都会在一次IO操作中被读取到缓存中，所以在访问同一个页中的不同记录时，会在内存里操作，而不用再次进行IO操作了。除非发生了页的分裂，即要查询的行数据不在上次IO操作的换村里，才会触发新的IO操作。
3.因为MyISAM的主索引并非聚簇索引，那么他的数据的物理地址必然是凌乱的，拿到这些物理地址，按照合适的算法进行I/O读取，于是开始不停的寻道不停的旋转。聚簇索引则只需一次I/O。（强烈的对比）
4.不过，如果涉及到大数据量的排序、全表扫描、count之类的操作的话，还是MyISAM占优势些，因为索引所占空间小，这些操作是需要在内存中完成的。
聚簇索引需要注意的地方
当使用主键为聚簇索引时，主键最好不要使用uuid，因为uuid的值太过离散，不适合排序且可能出线新增加记录的uuid，会插入在索引树中间的位置，导致索引树调整复杂度变大，消耗更多的时间和资源。
建议使用int类型的自增，方便排序并且默认会在索引树的末尾增加主键值，对索引树的结构影响最小。而且，主键值占用的存储空间越大，辅助索引中保存的主键值也会跟着变大，占用存储空间，也会影响到IO操作读取到的数据量。
为什么主键通常建议使用自增id
聚簇索引的数据的物理存放顺序与索引顺序是一致的，即：只要索引是相邻的，那么对应的数据一定也是相邻地存放在磁盘上的。如果主键不是自增id，那么可以想 象，它会干些什么，不断地调整数据的物理地址、分页，当然也有其他一些措施来减少这些操作，但却无法彻底避免。但，如果是自增的，那就简单了，它只需要一 页一页地写，索引结构相对紧凑，磁盘碎片少，效率也高。
四个隔离级别
我们先回忆一下事务的四个隔离级别，他们由弱到强如下所示:
select 分析的表数据
为了便于说明，我来个例子，假设有表数据如下，pId为主键索引
| pId(int) | name(varchar) | num(int) |
|---|---|---|
| 1 | aaa | 100 |
| 2 | bbb | 200 |
| 7 | ccc | 200 |
隔离级别：RC/RU ，条件列: 非索引
(1)select * from table where num = 200
不加任何锁，是快照读。
(2)select * from table where num > 200
不加任何锁，是快照读。
(3)select * from table where num = 200 lock in share mode
当num = 200，有两条记录。这两条记录对应的pId=2，7，因此在pId=2，7的聚簇索引上加行级S锁，采用当前读。
(4)select * from table where num > 200 lock in share mode
当num > 200，有一条记录。这条记录对应的pId=3，因此在pId=3的聚簇索引上加上行级S锁，采用当前读。
(5)select * from table where num = 200 for update
当num = 200，有两条记录。这两条记录对应的pId=2，7，因此在pId=2，7的聚簇索引上加行级X锁，采用当前读。
(6)select * from table where num > 200 for update
当num > 200，有一条记录。这条记录对应的pId=3，因此在pId=3的聚簇索引上加上行级X锁，采用当前读。
隔离级别：RC/RU ，条件列: 聚簇索引
大家应该知道pId是主键列，因此pId用的就是聚簇索引。此情况其实和RC/RU+条件列非索引情况是类似的。
(1)select * from table where pId = 2
不加任何锁，是快照读。
(2)select * from table where pId > 2
不加任何锁，是快照读。
(3)select * from table where pId = 2 lock in share mode
在pId=2的聚簇索引上，加S锁，为当前读。
(4)select * from table where pId > 2 lock in share mode
在pId=3，7的聚簇索引上，加S锁，为当前读。
(5)select * from table where pId = 2 for update
在pId=2的聚簇索引上，加X锁，为当前读。
(6)select * from table where pId > 2 for update
在pId=3，7的聚簇索引上，加X锁，为当前读。
为什么条件列加不加索引，加锁情况是一样的？
其实是不一样的。在RC/RU隔离级别中，MySQL做了优化。在条件列没有索引的情况下，尽管通过聚簇索引来扫描全表，进行全表加锁。但是，MySQL Server层会进行过滤并把不符合条件的锁当即释放掉，因此你看起来最终结果是一样的。但是RC/RU+条件列非索引比本例多了一个释放不符合条件的锁的过程！
隔离级别：RC/RU ，条件列: 非聚簇索引
在num列上建上非唯一索引。此时有一棵聚簇索引(主键索引，pId)形成的B+索引树，其叶子节点为硬盘上的真实数据。以及另一棵非聚簇索引(非唯一索引，num)形成的B+索引树，其叶子节点依然为索引节点，保存了num列的字段值，和对应的聚簇索引。
(1)select * from table where num = 200
不加任何锁，是快照读。
(2)select * from table where num > 200
不加任何锁，是快照读。
(3)select * from table where num = 200 lock in share mode
当num = 200，由于num列上有索引，因此先在 num = 200的两条索引记录上加行级S锁。接着，去聚簇索引树上查询，这两条记录对应的pId=2，7，因此在pId=2，7的聚簇索引上加行级S锁，采用当前读。
(4)select * from table where num > 200 lock in share mode
当num > 200，由于num列上有索引，因此先在符合条件的 num = 300的一条索引记录上加行级S锁。接着，去聚簇索引树上查询，这条记录对应的pId=3，因此在pId=3的聚簇索引上加行级S锁，采用当前读。
(5)select * from table where num = 200 for update
当num = 200，由于num列上有索引，因此先在 num = 200的两条索引记录上加行级X锁。接着，去聚簇索引树上查询，这两条记录对应的pId=2，7，因此在pId=2，7的聚簇索引上加行级X锁，采用当前读。
(6)select * from table where num > 200 for update
当num > 200，由于num列上有索引，因此先在符合条件的 num = 300的一条索引记录上加行级X锁。接着，去聚簇索引树上查询，这条记录对应的pId=3，因此在pId=3的聚簇索引上加行级X锁，采用当前读。
隔离级别：RR/Serializable，条件列: 非索引
RR级别需要多考虑的就是gap lock，他的加锁特征在于，无论你怎么查都是锁全表。接下来分析开始
(1)select * from table where num = 200
在RR级别下，不加任何锁，是快照读。
在Serializable级别下，在pId = 1,2,3,7（全表所有记录）的聚簇索引上加S锁。并且在
聚簇索引的所有间隙(-∞,1)(1,2)(2,3)(3,7)(7,+∞)加gap lock
(2)select * from table where num > 200
在RR级别下，不加任何锁，是快照读。
在Serializable级别下，在pId = 1,2,3,7（全表所有记录）的聚簇索引上加S锁。并且在
聚簇索引的所有间隙(-∞,1)(1,2)(2,3)(3,7)(7,+∞)加gap lock
(3)select * from table where num = 200 lock in share mode
在pId = 1,2,3,7（全表所有记录）的聚簇索引上加S锁。并且在
聚簇索引的所有间隙(-∞,1)(1,2)(2,3)(3,7)(7,+∞)加gap lock
(4)select * from table where num > 200 lock in share mode
在pId = 1,2,3,7（全表所有记录）的聚簇索引上加S锁。并且在
聚簇索引的所有间隙(-∞,1)(1,2)(2,3)(3,7)(7,+∞)加gap lock
(5)select * from table where num = 200 for update
在pId = 1,2,3,7（全表所有记录）的聚簇索引上加X锁。并且在
聚簇索引的所有间隙(-∞,1)(1,2)(2,3)(3,7)(7,+∞)加gap lock
(6)select * from table where num > 200 for update
在pId = 1,2,3,7（全表所有记录）的聚簇索引上加X锁。并且在
聚簇索引的所有间隙(-∞,1)(1,2)(2,3)(3,7)(7,+∞)加gap lock
隔离级别：RR/Serializable，条件列: 聚簇索引
大家应该知道pId是主键列，因此pId用的就是聚簇索引。该情况的加锁特征在于，如果where后的条件为精确查询(=的情况)，那么只存在record lock。如果where后的条件为范围查询(>或<的情况)，那么存在的是record lock+gap lock。
(1)select * from table where pId = 2
在RR级别下，不加任何锁，是快照读。
在Serializable级别下，是当前读，在pId=2的聚簇索引上加S锁，不存在gap lock。
(2)select * from table where pId > 2
在RR级别下，不加任何锁，是快照读。
在Serializable级别下，是当前读，在pId=3,7的聚簇索引上加S锁。在(2,3)(3,7)(7,+∞)加上gap lock
(3)select * from table where pId = 2 lock in share mode
是当前读，在pId=2的聚簇索引上加S锁，不存在gap lock。
(4)select * from table where pId > 2 lock in share mode
是当前读，在pId=3,7的聚簇索引上加S锁。在(2,3)(3,7)(7,+∞)加上gap lock
(5)select * from table where pId = 2 for update
是当前读，在pId=2的聚簇索引上加X锁。
(6)select * from table where pId > 2 for update
在pId=3,7的聚簇索引上加X锁。在(2,3)(3,7)(7,+∞)加上gap lock
(7)select * from table where pId = 6 [lock in share mode|for update]
注意了，pId=6是不存在的列，这种情况会在(3,7)上加gap lock。
(8)select * from table where pId > 18 [lock in share mode|for update]
注意了，pId>18，查询结果是空的。在这种情况下，是在(7,+∞)上加gap lock。
隔离级别：RR/Serializable，条件列: 非聚簇索引
这里非聚簇索引，需要区分是否为唯一索引。因为如果是非唯一索引，间隙锁的加锁方式是有区别的。
先说一下，唯一索引的情况。如果是唯一索引，情况和RR/Serializable+条件列是聚簇索引类似，唯一有区别的是:这个时候有两棵索引树，加锁是加在对应的非聚簇索引树和聚簇索引树上！大家可以自行推敲!
下面说一下，非聚簇索引是非唯一索引的情况，他和唯一索引的区别就是通过索引进行精确查询以后，不仅存在record lock，还存在gap lock。而通过唯一索引进行精确查询后，只存在record lock，不存在gap lock。老规矩在num列建立非唯一索引
(1)select * from table where num = 200
在RR级别下，不加任何锁，是快照读。
在Serializable级别下，是当前读，在pId=2，7的聚簇索引上加S锁，在num=200的非聚集索引上加S锁，在(100,200)(200,300)加上gap lock。
(2)select * from table where num > 200
在RR级别下，不加任何锁，是快照读。
在Serializable级别下，是当前读，在pId=3的聚簇索引上加S锁，在num=300的非聚集索引上加S锁。在(200,300)(300,+∞)加上gap lock
(3)select * from table where num = 200 lock in share mode
是当前读，在pId=2，7的聚簇索引上加S锁，在num=200的非聚集索引上加S锁，在(100,200)(200,300)加上gap lock。
(4)select * from table where num > 200 lock in share mode
是当前读，在pId=3的聚簇索引上加S锁，在num=300的非聚集索引上加S锁。在(200,300)(300,+∞)加上gap lock。
(5)select * from table where num = 200 for update
是当前读，在pId=2，7的聚簇索引上加S锁，在num=200的非聚集索引上加X锁，在(100,200)(200,300)加上gap lock。
(6)select * from table where num > 200 for update
是当前读，在pId=3的聚簇索引上加S锁，在num=300的非聚集索引上加X锁。在(200,300)(300,+∞)加上gap lock
(7)select * from table where num = 250 [lock in share mode|for update]
注意了，num=250是不存在的列，这种情况会在(200,300)上加gap lock。
(8)select * from table where num > 400 [lock in share mode|for update]
注意了，pId>400，查询结果是空的。在这种情况下，是在(400,+∞)上加gap lock。
MyISAM表锁是deadlock free的，这是因为MyISAM总是一次获得所需的全部锁，要么全部满足，要么等待，因此不会出现死锁。但在InnoDB中，除单个SQL组成的事务外，锁是逐步获得的，当两个事务都需要获得对方持有的排他锁才能继续完成事务，这种循环锁等待就是典型的死锁。
如何避免死锁？
为了在单个 InnoDB 表上执行多个并发写入操作时避免死锁，可以在事务开始时通过为预期要修改的每个元祖（行）使用 SELECT … FOR UPDATE 语句来获取必要的锁，即使这些行的更改语句是在之后才执行的。
在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁、更新时再申请排他锁，因为这时候当用户再申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁
如果事务需要修改或锁定多个表，则应在每个事务中以相同的顺序使用加锁语句。在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会
在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能。
在REPEATABLE-READ隔离级别下，如果两个线程同时对相同条件记录用SELECT...FOR UPDATE加排他锁，在没有符合该条件记录情况下，两个线程都会加锁成功。程序发现记录尚不存在，就试图插入一条新记录，如果两个线程都这么做，就会出现死锁。这种情况下，将隔离级别改成READ COMMITTED，就可避免问题。
当隔离级别为READ COMMITTED时，如果两个线程都先执行SELECT...FOR UPDATE，判断是否存在符合条件的记录，如果没有，就插入记录。此时，只有一个线程能插入成功，另一个线程会出现锁等待，当第1个线程提交后，第2个线程会因主键重出错，但虽然这个线程出错了，却会获得一个排他锁。这时如果有第3个线程又来申请排他锁，也会出现死锁。对于这种情况，可以直接做插入操作，然后再捕获主键重异常，或者在遇到主键重错误时，总是执行ROLLBACK释放获得的排他锁
InnoDB 默认是如何对待死锁的？
InnoDB 默认是使用设置死锁时间来让死锁超时的策略，默认 innodblockwait_timeout 设置的时长是 50s。
如何开启死锁检测？
设置 innodbdeadlockdetect 设置为 on 可以主动检测死锁，在 Innodb 中这个值默认就是 on 开启的状态。
乐观锁并不是真实存在的锁，而是在更新的时候判断此时的库存是否是之前查询出的库存，如果相同，表示没人修改，可以更新库存，否则表示别人抢过资源，不再执行库存更新。类似如下操作：
update tb_sku set stock=2 where id=1 and stock=7; SKU.objects.filter(id=1, stock=7).update(stock=2)
使用乐观锁的时候，如果一个事务修改了库存并提交了事务，那其他的事务应该可以读取到修改后的数据值，所以不能使用可重复读的隔离级别，应该修改为读取已提交（Read committed）。
修改方式：
| 事务隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 读未提交（read-uncommitted） | 是 | 是 | 是 |
| 不可重复读（read-committed） | 否 | 是 | 是 |
| 可重复读（repeatable-read） | 否 | 否 | 是 |
| 串行化（serializable） | 否 | 否 | 否 |
mysql默认的事务隔离级别为repeatable-read
1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据
2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。
3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。
小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表
三、MySQL事务隔离级别
Mysql默认的事务隔离级别为repeatable-read
四、用例子说明各个隔离级别的情况
1、读未提交：
（1）打开一个客户端A，并设置当前事务模式为read uncommitted（未提交读），查询表account的初始值：
（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account：
（3）这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：
（4）一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据：
（5）在客户端A执行更新语句update account set balance = balance - 50 where id =1，lilei的balance没有变成350，居然是400，是不是很奇怪，数据不一致啊，如果你这么想就太天真 了，在应用程序中，我们会用400-50=350，并不知道其他会话回滚了，要想解决这个问题可以采用读已提交的隔离级别
2、读已提交
（1）打开一个客户端A，并设置当前事务模式为read committed（提交读），查询表account的所有记录：
（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account：
（3）这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题：
（4）客户端B的事务提交
（5）客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题
3、可重复读
（1）打开一个客户端A，并设置当前事务模式为repeatable read，查询表account的所有记录
（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account并提交
（3）在客户端A查询表account的所有记录，与步骤（1）查询结果一致，没有出现不可重复读的问题
（4）在客户端A，接着执行update balance = balance - 50 where id = 1，balance没有变成400-50=350，lilei的balance值用的是步骤（2）中的350来算的，所以是300，数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC机制，select操作不会更新版本号，是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。
（5）重新打开客户端B，插入一条新数据后提交
（6）在客户端A查询表account的所有记录，没有 查出 新增数据，所以没有出现幻读
4.串行化
（1）打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值：
mysql> set session transaction isolation level serializable; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from account; +------+--------+---------+ | id | name | balance | +------+--------+---------+ | 1 | lilei | 10000 | | 2 | hanmei | 10000 | | 3 | lucy | 10000 | | 4 | lily | 10000 | +------+--------+---------+ 4 rows in set (0.00 sec)
（2）打开一个客户端B，并设置当前事务模式为serializable，插入一条记录报错，表被锁了插入失败，mysql中事务隔离级别为serializable时会锁表，因此不会出现幻读的情况，这种隔离级别并发性极低，开发中很少会用到。
mysql> set session transaction isolation level serializable; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> insert into account values(5,'tom',0); ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
补充：
1、事务隔离级别为读提交时，写数据只会锁住相应的行
2、事务隔离级别为可重复读时，如果检索条件有索引（包括主键索引）的时候，默认加锁方式是next-key 锁；如果检索条件没有索引，更新数据时会锁住整张表。一个间隙被事务加了锁，其他事务是不能在这个间隙插入记录的，这样可以防止幻读。
3、事务隔离级别为串行化时，读写数据都会锁住整张表
4、隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。
乐观锁在高并发场景下的问题，是严重的空自旋
具体可以参考 入大厂必备的基础书籍： 《Java高并发核心编程 卷2》
最优的解决方案，其实思想来自于JUC的原理
JUC是如何提高性能的，引入队列
原始的CLH队列
用于减少线程争用的最简单的队列，CLH队列，具体可以参考 入大厂必备的基础书籍： 《Java高并发核心编程 卷2》
JUC的AQS内部队列
AQS内部队列是JUC高性能的基础，AQS队列，具体可以参考 入大厂必备的基础书籍： 《Java高并发核心编程 卷2》
将提交操作变成两段式：
第一阶段申请，申请预减减库，申请成功之后，进入消息队列；
第二阶段确认，从消息队列消费申请令牌，然后完成下单操作。 查库存 -> 创建订单 -> 扣减库存。通过分布式锁保障解决多个provider实例并发下单产生的超卖问题。
申请阶段：
将存库从MySQL前移到Redis中，所有的预减库存的操作放到内存中，由于Redis中不存在锁故不会出现互相等待，并且由于Redis的写性能和读性能都远高于MySQL，这就解决了高并发下的性能问题。
确认阶段：
然后通过队列等异步手段，将变化的数据异步写入到DB中。
引入队列，然后数据通过队列排序，按照次序更新到DB中，完全串行处理。当达到库存阀值的时候就不在消费队列，并关闭购买功能。这就解决了超卖问题。
基于分段的排队执行方案的性能提升
一个高性能秒杀的场景：
假设一个商品1分钟6000订单，每秒的 600个下单操作。
在排队阶段，每秒的 600个预减库存的操作，对于 Redis 来说，没有任何压力。甚至每秒的 6000个预减库存的操作，对于 Redis 来说，也是压力不大。
但是在下单阶段，就不一样了。假设加锁之后，释放锁之前，查库存 -> 创建订单 -> 扣减库存，经过优化，每个IO操作100ms，大概200毫秒，一秒钟5个订单。600个订单需要120s，2分钟才能彻底消化。
如何提升下单阶段的性能呢？
可以使用Redis 分段锁。
为了达到每秒600个订单，可以将锁分成 600 /5 =120 个段，每个段负责5个订单，600个订单，在第二个阶段1秒钟下单完成。
有关Redis分段锁的详细知识，请阅读下面的博文：
基于分段的排队执行方案优点：
解决超卖问题，库存读写都在内存中，故同时解决性能问题。
基于分段的排队执行方案缺点：
由于异步写入DB，可能存在数据不一致，存在某一时刻DB和Redis中数据不一致的风险。
可能存在少买，也就是如果拿到号的人不真正下订单，可能库存减为0，但是订单数并没有达到库存阀值。
【原创】惊！史上最全的select加锁分析(Mysql) - 孤独烟 - 博客园
区分聚集索引、非聚集索引、聚簇索引、稀疏索引、稠密索引_iCoding91-CSDN博客_聚集索引和稀疏索引
__EOF__
本文作者：疯狂创客圈
本文链接：秒杀超卖 解决方案（史上最全） - 疯狂创客圈 - 博客园
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！
