MySQL

优点

缺点

优点

一个事务修改了另一个事务已修改但未提交的记录，那就意味着发生了脏写。

一个事务读取了另一个事务已修改但未提交的记录，那就意味着发生了脏读。

如果一个事务只能读取另一个已经提交的事务修改后的数据，并且另一个事务每对该数据进行一次修改并提交后，该事务都能查询到最新的值，那就意味着发生了不可重复读。

如果事务A先根据某些条件查询出一些记录，之后事务B又向表中插入了符合这些条件的记录，事务A再次按照该条件查询时，能把事务B插入的记录也读出来，那就意味着发生了幻读。

注意：如果事务B删除了符合条件的记录，事务A再次按照该条件查询，发现记录少了。这种情况并不算是幻读！幻读强调的是一个事务按照相同条件多次读取记录时，后续读到了之前没有读到的记录。对于之前已经读到的记录，之后又读不到这种情况，其实是算作不可重复读的现象。幻读只是强调了读取到了之前没有获取到的记录。

解决方法

一个事务覆盖了另一个事务对同一条数据的修改

解决方法

读未提交。啥都解决不了。

读已提交。可以解决脏读，但是不能解决不可重复读和幻读。

重复读。可以解决脏读，不可重复读，MySQL对RR级别的实现中可以禁止幻读发生。

串行，没有任何问题。并发性极低。

快照读：读操作用MVCC（无锁）来控制，读写分离

写操作用锁来控制，读写都要加锁

比较

以主键创建的索引

叶子节点存储的是主键和对应的数据行

是通往真实数据行的唯一途径。

创建带有主键的表默认使用的就是聚簇索引结构。如果没有主键，引擎会选取带有Unique键(唯一索引)作为主键。如果还没有唯一索引，引擎会自己偷偷给表添加一个row_id隐藏列作为主键来创建聚簇索引。

以普通字段创建的索引

叶子节点存储的是索引列和主键

查询时比聚簇索引慢。

平时对一条记录上的就是这个普通记录锁。记录锁也是分S锁和X锁的，满足S和X锁互斥，S S锁兼容的原则。

RR级别多次索引范围查询时，可是实现重复读，也同时避免了幻读。虽然防止了幻读，但是不能防止插入幻影记录。Gap Lock的出现仅仅就是为了解决插入幻影行的问题。

是Record Lock和Gap Lock的合体。即能保护当前记录，又能保护住插入间隙。

其他事务在向GAP间隙锁中插入记录时，会被阻塞并且获取该间隙中的插入意向锁，当GAP锁的事务结束时，才会去插入记录。插入意向锁并不会组织其他事务继续获取该记录上的其他任何类型的锁（就是个鸡肋）。

隐式锁是对于Insert语句来说的。事务在执行Insert时一般是不加锁的，一种特殊情况是插入到间隙时遇到了Gap锁，此时的insert会加插入意向锁。而由此引发了一个问题，如果insert不加锁，那插入后事务还未提交时，其他事务如果获取到了这条记录的S锁或者X锁，岂不是会发生脏读和脏写问题吗？这就需要知道Insert过程中的隐式锁了。我们都知道一条记录中包换隐藏列trx_id，记录了最近修改该条记录的事务id。因此当其他事务在尝试获取该记录的S锁或者X锁时，会先检查记录的trx_id是否为当前活跃的事务id，如果是，就帮助当前事务创建一个X锁以阻止其他事务读写，并且为自己也创建一个锁来进入等待状态。

row

statement

mixed

tx_id 事务id：只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为事务分配事务id，否则在一个只读事务中的事务id值都默认为0。

roll pointer 回滚指针：指向修改前版本的指针。

每条记录都必会有tx_id和roll pointer两个隐藏字段。不同事务对同一条记录的修改会形成一个版本链。

m_ids 系统当前活跃的事务id集合。

min_trx_id 当前活跃事务id中的最小值。

max_trx_id 系统即将给新事务分配的事务id值。

creator_id 创建当前ReadView的事务id。

RC级别下，每次查询开始时都会生成一个独立的ReadView。

RR级别下，只会在当前事务第一次查询时生成一个ReadView，之后的查询不会生成ReadView了。

redolog刷脏页中。因为写满了，要去同步磁盘。

遇到了表锁或者行锁，在等待中。

索引未生效，这里参考索引未生效的情况

存储引擎选错索引。引擎认为走全表比走索引快，导致全表扫描了。