事务
mysql中如何开启事务：
begin/start transaction --手工
commit/rollback --事务提交或回滚
set session autocommit = on/off
jdbc编程：connection.setAutoCommit(boolean); ***;connection.commit();
事务具有四个特性，也是面试常考的四个特性ACID：
A（原子性Atomicity）：原子性指的是事务是一个不可分割的，要么都执行要么都不执行。
C（一致性Consistency）：事务必须使得数据库从一个一致性状态，到另外一个一致性状态。
I（隔离性Isolation）：指的是一个事务的执行，不能被其他的事务所干扰。
D（持久性Durability）：持久性指的是一个事务一旦提交了之后，对数据库的改变就是永久的
隔离级别
MySQL是一个服务器／客户端架构的软件，对于同一个服务器来说，可以有若干个客户端与之连接，每个客户端与服务器连接上之后，就可以称之为一个会话（Session）。我们可以同时在不同的会话里输入各种语句，这些语句可以作为事务的一部分进行处理。不同的会话可以同时发送请求，也就是说服务器可能同时在处理多个事务，这样子就会导致不同的事务可能同时访问到相同的记录。我们前边说过事务有一个特性称之为隔离性，理论上在某个事务对某个数据进行访问时，其他事务应该进行排队，当该事务提交之后，其他事务才可以继续访问这个数据。但是这样子的话对性能影响太大，所以设计数据库的大叔提出了各种隔离级别，来最大限度的提升系统并发处理事务的能力，但是这也是以牺牲一定的隔离性来达到的。
未提交读（READ UNCOMMITTED）
如果一个事务读到了另一个未提交事务修改过的数据，那么这种隔离级别就称之为未提交读（英文名：READ UNCOMMITTED），示意图如下：
如上图，Session A和Session B各开启了一个事务，Session B中的事务先将id为1的记录的列c更新为'关羽'，然后Session A中的事务再去查询这条id为1的记录，那么在未提交读的隔离级别下，查询结果就是'关羽'，也就是说某个事务读到了另一个未提交事务修改过的记录。但是如果Session B中的事务稍后进行了回滚，那么Session A中的事务相当于读到了一个不存在的数据，这种现象就称之为脏读，就像这个样子：
脏读违背了现实世界的业务含义，所以这种READ UNCOMMITTED算是十分不安全的一种隔离级别。
已提交读（READ COMMITTED）
如果一个事务只能读到另一个已经提交的事务修改过的数据，并且其他事务每对该数据进行一次修改并提交后，该事务都能查询得到最新值，那么这种隔离级别就称之为已提交读（英文名：READ COMMITTED），如图所示：
从图中可以看到，第4步时，由于Session B中的事务尚未提交，所以Session A中的事务查询得到的结果只是'刘备'，而第6步时，由于Session B中的事务已经提交，所以Session B中的事务查询得到的结果就是'关羽'了。
对于某个处在在已提交读隔离级别下的事务来说，只要其他事务修改了某个数据的值，并且之后提交了，那么该事务就会读到该数据的最新值，比方说：
我们在Session B中提交了几个隐式事务，这些事务都修改了id为1的记录的列c的值，每次事务提交之后，Session A中的事务都可以查看到最新的值。这种现象也被称之为不可重复读。
可重复读（REPEATABLE READ）
在一些业务场景中，一个事务只能读到另一个已经提交的事务修改过的数据，但是第一次读过某条记录后，即使其他事务修改了该记录的值并且提交，该事务之后再读该条记录时，读到的仍是第一次读到的值，而不是每次都读到不同的数据。那么这种隔离级别就称之为可重复读（英文名：REPEATABLE READ），如图所示：
从图中可以看出来，Session A中的事务在第一次读取id为1的记录时，列c的值为'刘备'，之后虽然Session B中隐式提交了多个事务，每个事务都修改了这条记录，但是Session A中的事务读到的列c的值仍为'刘备'，与第一次读取的值是相同的。
但是仍然存在幻读问题：在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。
串行化（SERIALIZABLE）
以上3种隔离级别都允许对同一条记录进行读-读、读-写、写-读的并发操作，如果我们不允许读-写、写-读的并发操作，可以使用SERIALIZABLE隔离级别，示意图如下：
如图所示，当Session B中的事务更新了id为1的记录后，之后Session A中的事务再去访问这条记录时就被卡住了，直到Session B中的事务提交之后，Session A中的事务才可以获取到查询结果。
事务隔离级别的实现主要用到了锁以及MVCC
锁
锁是用于管理不同事务对共享资源的并发访问。
锁的分类
加锁机制：
1、乐观锁：先修改，保存时判断是够被更新过，应用级别
2、悲观锁：先获取锁，再操作修改，数据库级别
锁粒度：
表级锁：开销小，加锁快，粒度大，锁冲突概率大，并发度低，适用于读多写少的情况。
页级锁：BDB存储引擎
行级锁：Innodb存储引擎，默认选项，innodb存储引擎支持行锁和表锁（另类的行锁），行锁一定是作用在索引上的。
兼容性：
S锁，也叫做读锁、共享锁，对应于我们常用的 select * from users where id =1 lock in share mode
X锁，也叫做写锁、排它锁、独占锁、互斥锁，对应对于select * from users where id =1 for update
S锁 和 X锁是可以是表锁，也可以是行锁，下面这个表格是锁冲突矩阵，可以看到只有读锁和读锁之间兼容的，写锁和读锁、写锁都是冲突的。
共享锁和排它锁
锁模式可以看成实现锁的一个具体的“算法”。
记录锁、间隙锁、临键锁都是排它锁。
记录锁：单行记录上的锁，行锁是加在索引上的，封锁记录，记录锁也叫行锁。
间隙锁：锁定记录之间的范围，但不包含记录本身。在RU和RC两种隔离级别下，即使你使用select ... in share mode或select ... for update，也无法防止幻读（读后写的场景）。因为这两种隔离级别下只会有行锁，而不会有间隙锁。
临键锁(Next Key Lock): 记录锁+ 间隙锁，锁定一个范围，包含记录本身
具体临键锁使用实例可以参考这篇文章
https://blog.csdn.net/qq_40378034/article/details/90904573
意向锁(Intention Locks)
InnoDB为了支持多粒度(表锁与行锁)的锁并存，引入意向锁。意向锁是表级锁，
IS: 意向共享锁
IX: 意向排他锁
事务在请求某一行的S锁和X锁前，需要先获得对应表的IS、IX锁。
意向锁产生的主要目的是为了处理行锁和表锁之间的冲突，用于表明“某个事务正在某一行上持有了锁，或者准备去持有锁”。比如，表中的某一行上加了X锁，就不能对这张表加X锁。
如果不在表上加意向锁，对表加锁的时候，都要去检查表中的某一行上是否加有行锁，多麻烦
插入意向锁（Insert Intention Lock）
Gap Lock中存在一种插入意向锁，在insert操作时产生。
有两个作用：
和next-key互斥，阻塞next-key 锁，防止插入数据，这样就不会幻读。
插入意向锁互相是兼容的，允许相同间隙、不同数据的并发插入。
只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。这一点在实际应用中特别需要注意，不然的话可能导致大量的锁冲突，从而影响引发并发性能。
MVCC
MySQL 中 InnoDB 引擎支持 MVCC
应对高并发事务, MVCC 比单纯的加行锁更有效, 开销更小
MVCC 在读已提交（Read Committed）和可重复读（Repeatable Read）隔离级别下起作用
MVCC 既可以基于乐观锁又可以基于悲观锁来实现
InnoDB的MVCC，通过在每行记录后面保存两个隐藏的列来实现：一个保存了行的创建时间，一个保存行的过期时间（删除时间），当然，这里的时间并不是时间戳，而是系统版本号，每开始一个新的事务，系统版本号就会递增。在RR隔离级别下，MVCC的操作如下：
select操作。
InnoDB只查找版本早于（包含等于）当前事务版本的数据行。可以确保事务读取的行，要么是事务开始前就已存在，或者事务自身插入或修改的记录。
行的删除版本要么未定义，要么大于当前事务版本号。可以确保事务读取的行，在事务开始之前未删除。
insert操作。将新插入的行保存当前版本号为行版本号。
delete操作。将删除的行保存当前版本号为删除标识。
update操作。变为insert和delete操作的组合，insert的行保存当前版本号为行版本号，delete则保存当前版本号到原来的行作为删除标识。
由于旧数据并不真正的删除，所以必须对这些数据进行清理，innodb会开启一个后台线程执行清理工作，具体的规则是将删除版本号小于当前系统版本的行删除，这个过程叫做purge。
部分内容参考
网友评论