MyISAM与InnoDB关于锁方面的区别

MyISAM

select（不加任何修饰）默认加读锁（共享锁），并且只有读读不阻塞，其他读写，写读，写写都会阻塞。
为select修饰上排他锁，读读也将阻塞。
非聚集索引，

InnoDB

支持事务，默认sql语句将执行自动提交事务
加锁解锁分为两个步骤，commit为解锁。
InnoDB直接使用select进行读后，并未上锁，所以另一个事务可对其进行写锁。
上读锁需用lock in share mode修饰，其他事务就无法使用排他锁，显示加共享锁后支持读读，
当不走索引时，用的是表级锁，用到索引时是行级锁和gap锁。也支持意向共享锁IS和意向排他写锁IX。
锁粒度越细，开销越大。

InnoDB和MyISAM共性

数据库的锁分类

乐观锁实现
1.版本号

数据没更新一次，version+1，当要更新值时，取当前版本信息与第一次取出来的version值，如果相等则更新，否则失败。具体例子如下
先将两个session都设为自动提交，两个session都先同时读取版本号，然后先执行下面第二个图的session2此时读入version为0，session1也读入为0。此时先执行session2的更新，version+1变为1。然后执行session1的更新操作，需先使用乐观锁机制判断当前version是否等于之前所读到的version，不等则无法更新。


2.时间戳

数据库事务的四大特性

事务隔离级别以及各级别下的并发访问问题

事务并发访问引起的问题以及如何避免

RC、RR级别下的InnoDB的非阻塞读（快照读）如何实现

read view决定事务看到哪个版本的日志
可见性算法：DB_TRX_ID>=其他当前活跃事务ID，通过DB_ROLL_PTR取出undo log 直到DB_TRX_ID<其他当前活跃事务ID

RC级别下
事务开始后，第一条快照读创建一个快照，将其他活跃的事务记录，此后每次调用都会创建一个新的快照。所以RC下用快照读select能看到别的事务提交的增删改。

RR级别下
事务开始后，第一条快照读创建一个快照，将其他活跃的事务记录，此后再调用快照读还是用的同一个快照。所以RR下，首次使用快照读是在别人增删改之前的，则此后即便别的事务增删改并提交也读不到数据的变更。

伪MVCC(Multi-version concouruncy control)
读不加锁，读写不冲突。
伪是因为并没有实现多版本共存，undo log日志中的内容是串行化的结果，记录了多个事务的过程，不属于多版本共存。

在rr级别下，mvcc完全解决了重复读，但并不能真正的完全避免幻读，只是在部分场景下利用历史数据规避了幻读

对于快照读，mysql使用mvcc利用历史数据部分避免了幻读（在某些场景看上去规避了幻读），提升并发性能。

要完全避免，需要手动加锁将快照读调整为当前读（mysql不会自动加锁），然后mysql使用next-key完全避免了幻读，比如rr下，锁1（0，2，3，4），另一个线程的insert 3即被阻塞，在rc下，另一个线程仍然可以大摇大摆的插入，如本线程再次查询比如count，则会不一致。要真正避免，需要加next-key锁(行锁+gap锁)

InnoDB可重复读隔离级别(RR)下如何避免幻读

当前读和快照读



RC不支持gap锁

只对修改的部分数据周围上锁，如上图，修改9的话，对(6,9],(9,11]区间上锁，这样便防止了幻读现象发生。

需结合主键的范围来看，如下图，插入bb，6成功，因为b在c前，而插入dd，6失败，因为d在c后，此时算作(6,11]的范围内，因此会被block住。对临界值11做这种操作也会出现相同的结果。


不走索引会锁住整个表，因此，需要避免不走索引。