三种锁问题
1.丢失修改：火车票问题，让第一个人丢失了修改
2.不可重复读（幻象）：第二次读会读到不正确的数据（一个事务读到另一个已提交的事务）
3.读“脏”数据：A修改值后又回滚，B读到修改后的值，即脏数据；或者是一个事务读到了另一个事务未提交的数据
阻塞
定义：一个事务等待另一个事务开锁（释放占用的资源）
控制等待的时间：set @@nnodb_lock_wait_timeout=60;
设定事务在等待超时时是否回滚：set @@innodb_rollback_on_timeout=on;
(默认是off，代表不回滚)
死锁
定义：A等B开锁，B等A开锁，两个在互相等待
解决方法：1、超时后对事务回滚，参数innodb_lock_wait_timeout设置超时的时间
2、用wait-for graph进行死锁检测
解决三种问题的方案
1、读操作使用多版本并发控制**（MVCC）**，写操作加锁：生成readview，查询语句只能读生成readview之前已经提交的更改（read committed和repeatable read就是用这个方法），mvcc也称为一致性非锁定读
2、读、写操作都加锁
隔离级别
1、read uncommitted：脏读，不可重复读，幻读都可能发生
2、read committed：不可重复读，幻读可能发生，脏读不可能发生
3、repeatable read：幻读可能发生，脏读和不可重复读不可能发生
4、serializable：上述现象都不可能发生
（以上都是不加锁的情况）
锁定读
1、共享锁：S锁 select…lock in share mode（对读取的数据加S锁）
2、独占锁：X锁 select…for update（对读取的数据加X锁）
S锁和S锁是兼容的，其他都不兼容，会阻塞
加锁语句只有这两三句，但是根据事务的隔离级别，索引类型等条件会产生不同的锁。在隔离级别不大于read committed(read uncommitted、read committed)会为当前记录加正经记录锁。在隔离级别不小于repeatable read(repeatable read、serializable)会为当前记录加next-key锁
写操作
即delete，update，insert
delete：先在B+树中定位到这条记录的位置，然后获取这条记录的X锁，最后再执行delete mark操作
update：同理
insert：新插入的一条记录受隐式锁保护，不需要在内存中生成对应的锁结构
多粒度锁
分几个层次：库，表，页，行
表加锁就是粒度比较粗，占用资源少
行加锁就是粒度最细的，可以实现更精准的并发控制，但是占用资源大
意向共享锁：IS锁，事务给某条记录加S锁前，要在表级别加个IS锁
意向独占锁：IX锁，事务给某条记录加X锁前，要在表级别加个IX锁
作用：方便判断表中的记录是否有被上锁，避免用遍历的方式查看表中是否有被上锁
IX和S不兼容，X都不兼容
行级锁类型
1、record lock
名称：lock_rec_not_gap
记录锁：把一条记录锁上
即上述的S锁和X锁
2、gap lock
名称：lock_gap
gap锁：不允许别的事务在一条记录前的间隙插入新记录
作用：防止插入幻影记录
3、next_key lock
名称：lock_ordinary
next-key锁：是record锁和gap锁的合体，即保护该条记录，又防止别的事务对被保护记录前的间隙插入记录
4、隐式锁
insert语句是不需要在内存中生成锁结构
解释：一个事务对新插入的记录不加锁，别的事务要对这条记录加锁时，由于有隐式锁的存在，会给当前事务生成一个锁结构，在给另外一个事务生成一个锁结构，然后“另外一个事务”进入等待状态
投机取巧：不用时可以不加，它自己用时自己加
查看事务加锁情况
使用innodb_trx表
select * from information_schema.innodb_trx\G
使用innodb_locks表
select * from information_schema.innodb_locks;
使用innodb_lock_waits表
select * from information_schema.innodb_lock_waits;
使用show engine innodb status
