锁类型：
1.MyISAM 和 Memory 存储引擎使用的是表级锁,BDB 引擎使用的是页级锁，也支持表级锁。
2.InnoDB 存储引擎既支持行级锁，也支持表级锁，默认情况下使用行级锁。
3.表级锁:它是直接锁住整个表，开销小，加锁速度快，锁住颗粒大， 不会出现死锁的情况，应对并发情况极差。
4.行级锁:它直接锁住一条记录，开销大，加锁慢，锁住颗粒小， 发送锁冲突概率低，适合并发情况。（重点叙述)
(注：行级锁又分为共享锁和排他锁 悲观锁和乐观锁实际上是锁机制抽象的描述)
5.页级锁:它是锁住一个页面，在innodb中一个页面大小大概为16KB，它开销介于表锁和行锁之间，
可能会死锁，锁住颗粒大小也介于表锁和行锁之间，并发度也介于表锁和行锁之间(一般很少使用)。
不同锁影响的数据量不一样:
表锁 > 页锁 > 行锁
性能(锁对于数据的锁住的速度):
表锁 > 页锁 > 行锁
注:表锁虽然性能好但是并不适合并发,因为使用了表锁整张表会锁住,其他进程用户会阻塞。而行锁只会锁住一条数据。
InnoDB行级锁:
InnoDB有两种类型的行级锁，两种内部使用的意向锁；
· 共享锁(S)
· 排他锁(X)
· 意向共享锁(IS)
· 意向排他锁(IX)
· 悲观锁:抽象概念，并不真实存在(通过加锁来实现想要的效果)
· 乐观锁:抽象概念，并不真实存在(MVCC 不通过加锁来实现想要的效果)
注：意向锁是InnoDB存储引擎自动加的，不需要用户干预，对于普通select语句，InnoDB不会加任何锁，对于insert，update，delete语句，InnoDB会自动给涉及的数据加隐示排他锁。
锁冲突:
共享锁：除了和排他锁以外的锁使用都是兼容的不会造成冲突；
排他锁：排他锁与任何锁一起使用都会冲突造成锁等待需要释放；
共享锁和排他锁：（冲突）
共享锁和共享锁：（兼容）
排他锁和排他锁：（冲突）
共享锁：只可以读不可以写
排他锁：不可以读不可以写
注:当使用MySQL事务的时候，其实底层是通过行级锁来实现的。
锁的使用方式:
innoDB显示加共享锁：select * from table_name lock in share mode；
innoDB显示加排他锁：select * from table_name for update；
死锁:
出现原因:因为锁互相冲突，导致了回环等待，从而造成了死锁的出现；
表锁不会出现死锁的情况；
死锁演示：
凡是执行insert update delete 的时候 MySQL都会默认隐示加上排他锁：
innodb 应对死锁情况:
1.优先判断事务的大小 回滚事务小的(事务大小：操作的数据量 影响的颗粒大小)
2.若事务大小一致的话 会优先执行先执行的事务 后执行的事务抛出死锁异常(回滚需要手动)
innodb不具备页锁；
注：innodb会出现行锁会转化成表锁的情况；
行锁转表锁:
演示一:
上图所示：进程一给id=1的数据加上了排他锁，而进程二修改的示id=2的数据但是进程二却出现了锁等待的情况，出现这情况是因为innodb行锁被转换成表锁了。
即 ：若数据表中如果没有唯一键，主键那么行锁就会自动转换成表锁，因为innodb行级锁 是通过给索引加锁来实现的。
演示二:
如上图所示：进程一查询数据name = 川桑一号的时候加了排他锁，而进程二修改的数据是name = 川桑二号 但是却出现了锁等待。此种情况也是行锁转表锁了。因为user表虽然加上了id主键索引，但是在使用锁查询的时候 where条件使用的字段name并没有索引,从而导致了行锁转换成了表锁。所以在使用锁的时候where条件字段应该用建立了索引的字段防止行锁转表锁。
演示三:
如上图所示：进程一查询name = 川桑一号的数据并加上了共享锁，而进程二修改name = 川桑二号的数据 但是却还是出现了锁等待。原因同上。
(注:以上测试锁机制示例使用的MySQL5.7.26版本)
间隙锁：
即:锁住一个区间范围内的数据防止别人写入，默认innodb是开启间隙锁的，可以通过修改配置参数关闭间隙锁(官网并不推荐你这么做)
间隙锁主要应对的是幻读问题(此篇不赘述幻读问题)但是使用间隙锁过程中容易出现死锁的问题。
