mysql乐观锁 悲观锁 行锁 表锁 共享锁 排他锁

mysql乐观锁 悲观锁 行锁 表锁 共享锁 排他锁
在开始之前 先了解一下理论知识 这样可以为下面的做铺垫
事务常见问题
更新丢失（Lost Update）
原因：当多个事务选择同一行操作，并且都是基于最初选定的值，由于每个事务都不知道其他事务的存在，就会发生更新覆盖的问题。类比github提交冲突。
脏读（Dirty Reads）
原因：事务A读取了事务B已经修改但尚未提交的数据。若事务B回滚数据，事务A的数据存在不一致性的问题。
不可重复读（Non-Repeatable Reads）
原因：事务A第一次读取最初数据，第二次读取事务B已经提交的修改或删除数据。导致两次读取数据不一致。不符合事务的隔离性。
幻读（Phantom Reads）
原因：事务A根据相同条件第二次查询到事务B提交的新增数据，两次数据结果集不一致。不符合事务的隔离性。

MySQL 事务属性
事务是由一组SQL语句组成的逻辑处理单元，事务具有ACID属性。
原子性（Atomicity）：事务是一个原子操作单元。在当时原子是不可分割的最小元素，其对数据的修改，要么全部成功，要么全部都不成功。
一致性（Consistent）：事务开始到结束的时间段内，数据都必须保持一致状态。
隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的”独立”环境执行。
持久性（Durable）：事务完成后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

InnoDB发生死锁后一般能自动检测到，并使一个事务释放锁并回退，另一个事务获得锁，继续完成事务。
表级锁： 开销小，加锁快；不会出现死锁(因为MyISAM会一次性获得SQL所需的全部锁)；锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁： 开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。

行锁需要注意的是InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁

乐观锁
定义一个 版本(version) 字段 用来记录修改或者操作的记录 每次操作一次版本就更新
如果A进程访问的时候 把 version查出来 保存 在进行提交更新操作时 查看当前版本 与保存的版本是否一致, 一样的话就进行更新 不一样的话 重新执行
sql
update table set version=version+1 where version={保存的版本};
这个 和java的 CAS操作很像 在执行执行之前保存一下记录 执行中的话 对比一下和之前的记录是否一致 一致的话就执行 不一致就不断的重试

悲观锁
每次去取数据的时候 给他加个锁 取完之后再进行解锁 当其他进程访问的时候会造成堵塞挂起 直到解锁 才会接着执行

悲观锁
1.共享锁 共享锁指的就是对于多个不同的事务，对同一个资源共享同一个锁
2.排他锁 多个不同的事务，对同一个资源只能有一把锁

共享锁

lock in share mode

begin;
 SELECT * from test   lock in share mode;

排它锁

for update

begin;
select id from  users where id=13   for UPDATE  ; 
commit;

每次获取商品时，对该商品加排他锁。
期间其他用户阻塞等待访问该记录。
悲观锁适合写入频繁的场景。

行锁

begin;
select * from  users where id=13   for UPDATE  ; 
commit;

根据索引进行条件查询获取单条数据 ,如果没有索引或者索引失效 会造成 表锁
根据非主键含索引（name）进行查询，并且查询到数据，name字段产生行锁。
根据非主键不含索引（name）进行查询，查到或查不到数据，name字段产生表锁
我们用延时 来进行操作

A 进程 延迟了3秒 此时B 进程没有延迟 而B进程在等待A进程处理完毕在进行处理

不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。

表锁

begin;
select id * from  users    for UPDATE  ; 
commit;

没有条件全查 或者没有索引 此时此刻就是表锁

区间锁

begin;
select id * from  users  id >10   for UPDATE  ; 
commit;