数据库锁的种类包括：
==行锁、表锁、共享锁、排它锁、乐观锁、悲观锁==
按照锁粒度划分，可以将锁划分成
- 行锁🔒
- 表锁🔒
按照数据库管理角度划分，可以将锁分成排他锁和共享锁
- 共享锁🔒
- 排他锁🔒
按程序员角度划分，可分为乐观锁和悲观锁
- 乐观锁🔒
- 悲观锁🔒
==1、行锁 & 表锁==
行记录，表都是资源，锁是作用在这些资源上的。
当插入数据时，就锁定表，这叫做”锁表”；当更新数据时，就锁定行，这叫做”锁行”。
如果粒度比较小(比如行级锁)，可以 增加系统的并发量 但需要较大的系统开销，会影响到性能，出现 #死锁#。因为粒度小则操作的锁的数量会增加。
如果作用在表上，粒度大，开销小，维护的锁少，不会出现死锁，但是并发是相当昂贵的，因为锁定了整个表就限制了其它事务对这个表中其他记录的访问。
InnoDB 和 Oracle 支持行锁和表锁，MyISAM 只支持表锁
mysql的行锁是基于索引加载的，所以行锁是要加在索引响应的行上，即命中索引
img
如上图所示，数据库表中有一个主键索引和一个普通索引，Sql语句基于索引查询，命中两条记录。
此时行锁一锁就锁定两条记录，当其他事务访问数据库同一张表时，被锁定的记录不能被访问，其他的记录都可以访问到。
行锁演示：
img
img
行锁里面又细分了：记录锁、间隙锁、意向锁
# 记录锁
select * from [tb_name] where id = #{id} for update
id列上有唯一索引，并且查询条件可以唯一确定一条记录，这时候innodb使用记录锁，只会锁住查出来的这一行记录
# 间隙锁
where后面的字段有索引，但不是唯一索引，或者使用了>, < 等范围的查询条件时，查询条件范围内的索引值之间的间隙会被加锁，结果就是被加锁的间隙之间不能插入索引值
表锁响应的是非索引字段，即==全表扫描==，全表扫描时锁定整张表，sql语句可以通过执行计划看出扫描了多少条记录。
img
img
==可以看到，当更新数据库数据时，如果没有触发索引，则会锁表，锁表后再对表做任何变更操作都会导致锁冲突，所以表锁的锁冲突概率较高。==
# 表锁分5类：共享锁（S锁）、排它锁（X锁）、行级共享锁（RS锁）、行级排它锁（RX锁）、共享行级排它锁（SRX锁）
==2、共享锁 & 排他锁==
共享锁，也叫读锁，或者 S 锁，共享锁锁定的资源可以被其他用户读取，但不能修改。
在进行 SElECT 的时候，会将对象进行共享锁锁定，当数据读取完毕之后，就会释放共享锁，这样就可以保证数据在读取时不被修改。
给某个表加共享锁：
lock table goods read;
当数据表加上共享锁的时候，该表数据就会变成只读模式，当时我们想更新 goods 表中的数据会报错，比如：
update goods set good_id = 12345 where user_id = 95678;
系统报错如下：
ERROR 1099 (HY000): Table 'goods' was locked with a READ lock and can't be updated
对表共享锁进行解锁：
unlock table; -- 会释放当前会话的所有锁
给某数据行加锁
select ... where ... lock table tablename in share mode 语法锁定整个表
排他锁，也叫做独占锁，写锁或者 X 锁，排他锁锁定的数据只允许进行锁定操作的事务使用，
其他事务无法对已锁定的数据进行查询或者修改。
给某个表加排他锁：
lock table goods write;
排他锁的事务可以对 goods 进行查询和修改。其他事务如果想要在 goods 表上查询数据，则需要等待。
对排他锁进行解锁：
unlock table;
给某行数据加排他锁
select ... for update
当我们对数据进行更新的时候会自动使用排他锁，也就是 insert ，delete 或者 update 的时候，数据库自动使用排他锁，防止其他事务对改数据进行操作。
==3、乐观锁 & 悲观锁==
img
乐观锁总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。**乐观锁适用于多读的应用类型，这样可以提高吞吐量。
版本号机制：
一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
update ... set version=version+1 where version=version
悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
通过数据库自身的锁机制来实现，从而保证数据操作的排他性
==乐观锁适合读操作多的场景; 悲观锁适合写操作多的场景==
非原创，搬代码的小工整理。。。
