MySQL++：乐观锁、悲观锁、共享锁、排它锁、行锁、表锁 概念
1、乐观锁
乐观锁不是数据库自带的，需要我们自己去实现。
乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突。
在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。
通常实现是这样的：👇
在表中的数据进行操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1。
也就是先查询出那条记录，获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等；
如果相等，则说明这段期间，没有其他程序对其进行操作，则可以执行更新，将version字段的值加1；
如果更新时发现此刻的version值与刚刚获取出来的version的值不相等，则说明这段期间已经有其他程序对其进行操作了，则不进行更新操作。
举例：👇
update t_goods set status=2,version=version+1 where id=#{id} and version=#{version};
除了自己手动实现乐观锁之外，现在网上许多框架已经封装好了乐观锁的实现，如hibernate，需要时，可以自行搜索"hiberate 乐观锁"试试看。
2、悲观锁
与乐观锁相对应的就是悲观锁了。
悲观锁就是在操作数据时，认为此操作会出现数据冲突，所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作，这点跟java中的synchronized很相似，所以悲观锁需要耗费较多的时间。
另外与乐观锁相对应的，悲观锁是由数据库自己实现了的，要用的时候，我们直接调用数据库的相关语句就可以了。
说到这里，由悲观锁涉及到的另外两个锁概念就出来了，它们就是共享锁与排它锁。
共享锁和排它锁是悲观锁的不同的实现，它俩都属于悲观锁的范畴。
2.1：共享锁
共享锁指的就是对于多个不同的事务，对同一个资源共享同一个锁。
都能访问到数据，但是只能读不能修改。
相当于对于同一把门，它拥有多个钥匙一样。
就像这样，你家有一个大门，大门的钥匙有好几把，你有一把，你女朋友有一把，你们都可能通过这把钥匙进入你们家，进去啪啪啪啥的，一下理解了哈，没错，这个就是所谓的共享锁。
刚刚说了，对于悲观锁，一般数据库已经实现了，共享锁也属于悲观锁的一种，那么共享锁在mysql中是通过什么命令来调用呢。
通过查询资料，了解到通过在执行语句后面加上 lock in share mode就代表对某些资源加上共享锁了。
比如，我这里通过mysql打开两个查询编辑器，在其中开启一个事务，并不执行commit语句。
city 表DDL如下：
CREATE TABLE city ( id bigint(20) NOT NULL AUTO_INCREMENT, name varchar(255) DEFAULT NULL, state varchar(255) DEFAULT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8;
begin;
SELECT * from city where id = "1" lock in share mode;
然后在另一个查询窗口中，对id为1的数据进行更新
update city set name="666" where id ="1";
此时，操作界面进入了卡顿状态，过几秒后，也提示错误信息
[SQL]update city set name="666" where id ="1"; [Err] 1205 - Lock wait timeout exceeded; try restarting transaction
那么证明，对于id=1的记录加锁成功了，在上一条记录还没有commit之前，这条id=1的记录被锁住了，只有在上一个事务释放掉锁后才能进行操作，或用共享锁才能对此数据进行操作。
再实验一下：
update city set name="666" where id ="1" lock in share mode;
报错：
[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'lock in share mode' at line 1
加上共享锁后，也提示错误信息了，通过查询资料才知道，对于 update,insert,delete 语句会自动加排它锁的原因
于是，我又试了试 SELECT * from city where id = "1" lock in share mode; 这下成功了。
2.2：排他锁
排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存，如一个事务获取了一个数据行的排他锁；
其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。
与共享锁类型，在需要执行的语句后面加上 for update 就可以了
3、行锁
行锁，由字面意思理解，就是给某一行加上锁，也就是一条记录加上锁。
InnoDB 行锁是通过给索引上的索引项加锁来实现的。
所以，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。
其他注意事项：
~ 在不通过索引条件查询的时候，InnoDB使用的是表锁，而不是行锁。
~ 由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以即使是访问不同行的记录，如果使用了相同的索引键，也是会出现锁冲突的。
~ 当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。
~ 即便在条件中使用了索引字段，但具体是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的；
如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。
因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。
隐式加锁：
~ InnoDB自动加意向锁。
~ 对于 UPDATE、DELETE 和 INSERT 语句，InnoDB会自动给涉及数据集加排他锁（X)；
~ 对于普通SELECT语句，InnoDB不会加任何锁；
显示加锁：
~ 共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
~ 排他锁（X) ：SELECT * FROM table_name WHERE ... FOR UPDATE
4、表锁
表锁，和行锁相对应，给这个表加上锁。
5、间隙锁
间隙锁定义：
nnodb的锁定规则是通过在指向数据记录的第一个索引键之前和最后一个索引键之后的空域空间上标记锁定信息而实现的。
Innodb的这种锁定实现方式被称为间隙锁，因为Query执行过程中通过范围查找的话，它会锁定整个范围内所有的索引键值，即使这个键值并不存在。
例：假如emp表中只有101条记录，其empid的值分别是 1,2,…,100,101，下面的SQL：
select * from emp where empid > 100 for update;
是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。
间隙锁的缺点：
~ 间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。
~ 在某些场景下这可能会对性能造成很大的危害 当Query无法利用索引的时候， Innodb会放弃使用行级别锁定而改用表级别的锁定，造成并发性能的降低；
~ 当Quuery使用的索引并不包含所有过滤条件的时候，数据检索使用到的索引键所指向的数据可能有部分并不属于该Query的结果集的行列，但是也会被锁定，因为间隙锁锁定的是一个范围，而不是具体的索引键；
~ 当Query在使用索引定位数据的时候，如果使用的索引键一样但访问的数据行不同的时候（索引只是过滤条件的一部分），一样会被锁定。
间隙锁的作用：
防止幻读，以满足相关隔离级别的要求。 为了数据恢复和复制的需要。
注意：
在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。
InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁。
人生无常大肠包小肠
