建站一条龙设计制作,怎样更换网站cms,自建网站流程,wordpress房地产主题锁的分类图#xff0c;如下#xff1a; 锁操作类型划分 读锁 : 也称为共享锁 、英文用S表示。针对同一份数据#xff0c;多个事务的读操作可以同时进行而不会互相影响#xff0c;相互不阻塞的。 写锁 : 也称为排他锁 、英文用X表示。当前写操作没有完成前#xff0c;它会…锁的分类图如下 锁操作类型划分 读锁 : 也称为共享锁 、英文用S表示。针对同一份数据多个事务的读操作可以同时进行而不会互相影响相互不阻塞的。 写锁 : 也称为排他锁 、英文用X表示。当前写操作没有完成前它会阻断其他写锁和读锁。这样就能确保在给定的时间里只有一个事务能执行写入并防止其他用户读取正在写入的同一资源。 对于InnoDB引擎读锁和写锁可以加在表上或者行上
1.锁定读 对读取的记录加S锁:
select...lock in share mode;
#或
select...for share;#(8.0新增语法)。。
若当前事务执行了该语句则会给该记录加S锁并允许别的事务继续获取该记录的S锁比如别的事务也使用 SELECT... LOCK IN SHAREMODE 语句来读取这些记录
但是不能获取这些记录的X锁比如别的事务不能直接修改这些记录会阻塞直到当前事务提交之后将这些记录上的S锁释放掉。 对读取的记录加X锁:
select...for update;
如果当前事务执行了该语句则会给该记录加X锁即不允许别的事务获取这些事务S锁也不允许获取X锁...
MySQL8新特性
在8.0版本中SELECT ... FOR UPDATE, SELECT .. FOR SHARE 添加NOWAIT、 SKIP LOCKED 语法跳过锁等待或者跳过锁定。 通过添加NOWAIT、SKIP LOCKED语法能够立即返回。如果查询的行已经加锁: 那么NOWAIT会立即报错返回 而SKIP LOCKED也会立即返回只是返回的结果中不包含被锁定的行 2.写操作
写操作无非是deleteupdateinsert DELETE 底层是先在 B 树中定位到这条记录的位置然后获取这条记录的X锁再执行 delete操作。 UPDATE 情况1: 未修改该记录的键值并且被更新的列占用的存储空间在修改前后未发生变化。 则在 B 树中定位到这条记录的位置然后获取记录的 X锁最后在原记录的位置进行修改操作。 情况2: 修改了该记录的键值则相当于在原记录上做 DELETE 操作之后再来一次INSERT操作加锁操作。需要按照 DELETE 和 INSERT 的规则进行了。
2.意向锁
InnoDB 支持多粒度锁它允许行级锁与表级锁共存而意向锁就是其中的一种表锁 意向锁的存在是为了协调行锁和表锁的关系 意向锁是一种不与行级锁冲突表级锁 这一点非常重要 意向锁是自动创建的自动声明其上级获取过锁这一动作轮到时就会有排队权
意向锁分为两种 意向共享锁: 事务有意向对表中的某些行加共享锁(S锁)
#事务要获取某些行的S锁必须先获得表的IS 锁。
select column from table ... lock in share mode; 意向排他锁: 事务有意向对表中的某些行加排他锁(X锁)
#事务要获取某些行的X锁必须先获得表的 IX 锁
select column from table ... for update;
意向锁是由存储引擎自己维护的 用户无法手动操作意向锁在为数据行加共享/排他锁之前InooDB 会先获取该数据行所在数据表的对应意向锁
意向锁作用
现在有两个事务T1和T2其中T2试图在该表级别上应用共享或排它锁 如果没有意向锁存在那么T2就需要去检查各个页或行是否存在锁 如果存在意向锁那么此时就会受到由T1控制的表级别意向锁的阻塞T2在锁定该表前不必检查各个页或行锁而只需检查表上的意向锁。其实就是在更大一级别的空间示意里面是否已经上过锁! 在数据表的场景中如果我们给某一行数据加上了排它锁数据库会自动给更大一级的空间比如数据页或数据表加上意向锁告诉其他人这个数据页或数据表已经有人上过排它锁了这样当其他人想要获取数据表排它锁的时候只需要看是否有人已获取这个数据表的意向排他锁即可 假设事务A获取了某一行的排他锁并未提交
begin;
select * from teacher where id6 for update;
事务B想要获取teacher表的读锁语句如下
begin;
lock tables teacher read;
因为共享锁与排他锁互斥所以事务B在试图对 teacher 表加共享锁的时候必须保证两个条件。 当前没有其他事务持有 teacher 表的排他锁 当前没有其他事务持有 teacher 表中任意一行的排他锁
为了检测是否满足第二个条件事务B必须在确保 teacber 表不存在任何排他锁的前提下去检测表中的每一行是否存在排他锁。很明显这是一个效率很差的做法但是有了意向锁之后情况就不一样了。
总结 意向锁是一个虚拟的锁只是为了让别的事务知道 这里有行级锁 所以不能加某些表级锁
3.自增锁
在使用MySQL过程中我们可以为表的某个列添加 AUTO_INCREMENT属性。举例
CREATE TABLE teacher (id int NOT NULL AUTO_INCREMENT,name varchar(255) NOT NULL,PRIMARY KEY (id)
) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_0900_ai_ci;
这意味着插入语句时不需要为其赋值SQL语句修改如下所示
INSERT INTO teacher (name) VALUES (zhangsan), (lisi);
#上边的插入语句并没有为id列显式赋值所以系统会自动为它赋上递增的值结果如下所示
mysql select * from teacher;
--------------
| id | name |
--------------
| 1 | zhangsan |
| 2 | lisi |
--------------
2 rows in set (0.00 sec)
所有插入数据的方式总共分为三类分别是:“ Simple inserts ”“ Bulk inserts ”和“ Mixed-mode inserts ”。 对于上面案例MySQL中采用了自增锁 的方式来实现自增锁是向含有AUTO_INCREMENT列的表中插入数据时的一种特殊的表级锁在执行插入语句时加一个AUTO-INC锁分配递增的值执行结束后再把AUTO-INC锁释放掉。
一个事务在持有AUTO-INC锁的过程中其他事务的插入语句都要被阻塞可以保证一个语句中分配的递增值是连续的。也正因为此其并发性不高当我们向一个有AUTO_INCREMENT关键字的主键插入值的时候每条语句都要对这个表锁进行竞争这样的并发潜力其实是很低下的所以innodb通过 innodb_autoinc_lock_mode的不同取值来提供不同的锁定机制来显著提高SQL语句的可伸缩性和性能。
#innodb_autoinc_lock_mode0(传统锁定模式)
所有insert语句都会获得自增锁这种锁定是全局性的即它会阻止其他事务同时进行插入操作直到当前插入完成即上面例子并发性差
#innodb_autoinc_lock_mode1(连续锁定模式)
mysql8之前的默认模式当执行 INSERT 时InnoDB 会先检查是否有可用的自增值如果有则立即分配该值给新行然后才加锁
#innodb_autoinc_lock_mode2(交错锁定模式)
InnoDB 会预先分配一组自增ID数量由 innodb_autoinc_cache 控制然后将这些ID分配给后续的插入操作多个客户端可以同时从预分配的ID池中获取ID并插入新行从而大大减少了锁等待的时间但由于多个语句会同时需要数字所以任何给定插入的行生成的值可能不是连续的
4.元数据锁MDL锁
MDL 的作用是保证读写的正确性。比如如果一个查询正在遍历一个表中的数据而执行期间另一个线程对这个表结构做变更 增加了一列那么查询线程拿到的结果跟表结构对不上肯定是不行的。
因此当对一个表做增删改查操作的时候加MDL读锁当要对表做结构变更操作的时候加 MDL写锁。解决DML和DDL操作之间的一致性问题不需要显式使用在访问一个表时会自动加上 2.行级锁
2.行级锁
顾名思义就是锁住页中某一行记录注意点是 行级锁只在存储引擎层实现锁的力度小发生锁冲突概率低并发度高
缺点是对于锁的开销比较大加锁会比较慢容易出现死锁情况
数据准备
CREATE TABLE accounts (id INT PRIMARY KEY,balance DECIMAL(10, 2)
);
INSERT INTO accounts (id, balance) VALUES (1, 1000), (2, 2000);
记录锁
记录锁仅仅把一条记录 锁上官方的类型名称为:LOCK_REC_NOT_GAP。比如我们把id值为8的那条记录加一个记录锁如图所示仅仅是锁住了id值为8的记录对周围的数据没有影响。 记录锁是有S锁和X锁之分的称之为 S型(读)记录锁 和 X型(写)记录锁 当一个事务获取了一条记录的读锁后其他事务可以继续获取该记录的读锁但不可以继续获取写锁 当一个事务获取了一条记录的写锁后其他事务既不可以获取该记录的读锁也不可以继续获取写锁。
死锁
接下来我们来看一个可能引起死锁的情况假设事务 D 和事务 E 同时运行并且它们都试图更新两个账户的余额
-- 启动事务 D
START TRANSACTION;
-- 获取账户1的排他锁
SELECT * FROM accounts WHERE id 1 FOR UPDATE;
-- 启动事务 E
START TRANSACTION;
-- 获取账户2的排他锁
SELECT * FROM accounts WHERE id 2 FOR UPDATE;
-- 事务 D 试图获取账户 2 的排他锁
SELECT * FROM accounts WHERE id 2 FOR UPDATE;
-- 事务 E 试图获取账户 1 的排他锁
SELECT * FROM accounts WHERE id 1 FOR UPDATE; 事务D已经获得了账户1的排他锁而事务E已经获得了账户2的排他锁。 当事务D试图获取账户2的排他锁时它会被阻塞同样地当事务 E 试图获取账户 1 的排他锁时也会被阻塞。这就会形成一个死锁的情况。 InnoDB 会检测到这种情况并自动解决死锁。它会选择一个事务回滚以便另一个事务可以继续执行。 可以通过查看 INFORMATION_SCHEMA.INNODB_TRX 表来了解当前的事务状态包括死锁信息
间隙锁
MySQL 在可重复读隔离级别下是可以解决幻读问题的解决方案有两种 可以使用 MVCC方案解决 也可以采用加锁方案解决。
但是事务在第一次执行读取操作时那些幻影记录尚不存在我们无法给这些幻影记录加上记录锁 所以InnoDB提出了一种称之为Gap Locks 的锁官方的类型名称为 LOCK_GAP 我们可以简称为 gap 锁 间隙锁 间隙锁是在行级别的锁定之上的一种扩展它不仅锁定具体的行的两边还锁定行之间的间隙 gap锁的提出仅仅是为了防止插入幻影记录而提出的
这种锁定是为了防止其他事务插入新的行到已经被锁定的数据行之间从而保证了事务的隔离性和一致性。 图中id值为8的记录加了gap锁意味着 不允许别的事务在id为3记录后的间隙即不允许315之间插入新记录
类型
插入意向间隙锁 插入意向间隙锁告诉其他事务这里即将发生插入操作因此其他事务不应该在该位置进行插入
普通间隙锁 执行 SELECT ... FOR UPDATE 或 SELECT ... FOR SHARE 查询时InnoDB 会在查询范围内的所有数据行上放置锁并在这些行之间的间隙上放置间隙锁 普通间隙锁用于防止其他事务在已锁定的数据行之间插入新行
举例
-- 有一个表 orders其中包含 order_id 和 order_amount 字段
CREATE TABLE orders (order_id INT AUTO_INCREMENT PRIMARY KEY,order_amount DECIMAL(10, 2)
);
INSERT INTO orders (order_amount) VALUES (100), (500), (1000);
现在我们有两个事务 A 和 B。事务 A 执行一个范围查询
-- 启动事务 A
START TRANSACTION;
-- 获取订单金额在200 到 600之间的排他锁
SELECT * FROM orders WHERE order_amount BETWEEN 200 AND 600 FOR UPDATE;
-- 事务A在200和600之间的间隙上放置了间隙锁。这意味着其他事务不能在这个范围内插入新的行
示例 2: 插入意向间隙锁
-- 启动事务 B
START TRANSACTION;
-- 尝试插入一个新的订单
INSERT INTO orders (order_amount) VALUES (300);
#事务B将被阻塞因为它试图在事务A已经锁定的间隙内插入新的行
临键锁
官方的类型名称为 LOCK_ORDINARY我们也可以简称为next-key锁 。Next-Key Locks是在存储引擎 innodb 、事务级别在可重复读的情况下使用的数据库锁innodb默认的锁就是临键锁
Next-Key Locks 是一种组合锁它同时包含了记录锁和间隙锁。简单来说会在一个记录上放置一个记录锁并且在该记录间隙上放置一个间隙锁。
举例
-- 有一个表 orders其中包含 order_id 和 order_amount 字段
CREATE TABLE orders (order_id INT AUTO_INCREMENT PRIMARY KEY,order_amount DECIMAL(10, 2)
);
INSERT INTO orders (order_amount) VALUES (100), (500), (1000);
现在我们有两个事务A和B。事务A执行一个范围查询
-- 启动事务 A
START TRANSACTION;
-- 获取订单金额在200到600 之间的排他锁
SELECT * FROM orders WHERE order_amount BETWEEN 200 AND 600 FOR UPDATE;
-- 事务A会在 order_amount 为 500 的行上放置一个排他锁并在200和600之间的所有间隙上放置间隙锁。这意味着其他事务不能在这个范围内插入新的行
现在事务 B 尝试插入一个新的订单
-- 启动事务 B
START TRANSACTION;
-- 尝试插入一个新的订单
INSERT INTO orders (order_amount) VALUES (300);
-- 事务 B 将被阻塞因为它试图在事务 A 已经锁定的间隙内插入新的行
如果您希望避免临键锁可以将事务隔离级别设置为 READ COMMITTED
-- 设置事务隔离级别为 READ COMMITTED
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 启动事务 A
START TRANSACTION;
-- 获取订单金额在 200 到 600 之间的排他锁
SELECT * FROM orders WHERE order_amount BETWEEN 200 AND 600 FOR UPDATE;
-- 在这种情况下事务 A 仅在匹配的行上放置排他锁而不会在行之间的间隙上放置间隙锁
插入意向锁
InnoDB规定事务在等待的时候也需要在内存中生成一个锁结构表明有事务想在某个间隙中插入新记录但是现在在等待。InnoDB就把这种类型的锁命名为 Insert Intention Locks 官称为插入意向锁
工作原理
假设事务 T1 对区间 [10, 20] 之间的所有行以及这个区间的间隙持有 Next-Key Locks。这时事务 T2 尝试在区间 [10, 20] 内插入一行数据比如插入 15。 T2 产生插入意向锁由于 T1 持有该间隙上的锁T2 无法立即插入数据但它会在内存中创建一个插入意向锁表示它想要在间隙 [10, 20] 中插入数据。 T2 等待T2 的插入操作被阻塞等待 T1 的事务结束 T1 提交或回滚当 T1 完成并释放其锁后T2 的插入意向锁变为有效T2 可以继续插入数据。
小结 通过使用插入意向锁系统可以更好地管理事务之间的等待顺序减少死锁的可能性 它允许事务声明插入意图并在等待间隙锁释放的过程中保持一定的灵活性
页锁
页锁就是在页的粒度上进行锁定锁定的数据资源比行锁要多因为一个页中可以有多个行记录
当我们使用页锁的时候会出现数据浪费的现象但这样的浪费最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间会出现死锁。锁定粒度介于表锁和行锁之间并发度一般
加锁的态度划分
乐观锁和悲观锁并不是锁而是锁的 设计思想从名字中也可以看出这两种锁是两种看待数据并发的思维方式
①悲观锁
顾名思义就是很悲观总是假设最坏的情况每次去拿数据的时候都认为别人会修改所以每次在拿数据的时候都会上锁这样别人想拿这个数据就会 阻塞 直到它拿到锁共享资源每次只给一个线程使用其它线程阻塞用完后再把资源转让给其它线程
比如行锁表锁等读锁写锁等都是在做操作之前先上锁当其他线程想要访问数据时都需要阻塞挂起。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现 实现方式: 使用行级锁或表级锁例如可以使用 SELECT...FOR UPDATE或LOCK INSHARE MODE语句来加锁。 悲观锁适合并发冲突多写多读少的场景。通过每次加锁的形式来确保数据的安全性吞吐量较低。
-- 读取数据并加锁
SELECT id, name FROM users WHERE id 1 FOR UPDATE;
-- 执行更新操作
UPDATE users SET name new_name WHERE id 1;
秒杀案例
其实就是简单的加锁解锁用户发起秒杀请求 检查库存查询商品库存是否大于0。 获取悲观锁如果库存大于0则尝试获取商品对应的悲观锁 扣减库存在锁定状态下执行扣减库存的操作。 释放锁成功扣减库存后释放悲观锁。 返回结果向用户返回秒杀成功或失败的消息。
诸如 还有微服务中的分布式锁其实也差不多
②乐观锁
认为对同一数据的并发操作不会总发生属于小概率事件不用每次都对数据上锁
但是在更新的时候会判断一下在此期间别人有没有去更新这个数据不采用锁机制而是通过程序来实现。在程序上我们可以采用版本号机制或者CAS机制实现。乐观锁适用于多读的应用类型这样可以提高吞吐量。
-- 假设有一张用户表 users包含 id、name 和 version 字段
-- 读取数据
SELECT id, name, version FROM users WHERE id 1;
-- 更新数据时检查版本号
UPDATE users
SET name new_name, version version 1
WHERE id 1 AND version current_version;
在Java中 java.util.concurrent.atomic 包下的原子变量类就是使用了乐观锁的一种实现方式CAS实现的 适用场景 加锁的方式划分
①隐式锁
顾名思义看不到的锁简单来说就是在一个事务中执行新插入一条记录操作并不加锁但是会给该插入操作加隐式锁的结构对这条插入记录进行保护防止该记录被其他事务访问
案例
-- session 1:
mysql begin;
Query OK, 0 rows affected (0.00 sec)
mysql insert INTO student VALUES(34,周八,二班);
Query OK, 1 row affected (0.00 sec)
-- session 2
mysql begin;
Query OK, 0 rows affected (0.00 sec)
mysql select * from student lock in share mode; #执行完当前事务被阻塞
mysql SELECT * FROM performance_schema.data_lock_waits\G;
*************************** 1. row ***************************ENGINE: INNODBREQUESTING_ENGINE_LOCK_ID: 140562531358232:7:4:9:140562535668584
REQUESTING_ENGINE_TRANSACTION_ID: 422037508068888REQUESTING_THREAD_ID: 64REQUESTING_EVENT_ID: 6
REQUESTING_OBJECT_INSTANCE_BEGIN: 140562535668584BLOCKING_ENGINE_LOCK_ID: 140562531351768:7:4:9:140562535619104
BLOCKING_ENGINE_TRANSACTION_ID: 15902BLOCKING_THREAD_ID: 64BLOCKING_EVENT_ID: 6
BLOCKING_OBJECT_INSTANCE_BEGIN: 140562535619104
1 row in set (0.00 sec)
分析 上述insert 语句 只是给新插入的那一行上了隐式锁 后面select * 是给全表上读锁 因为后面要给全表记录上锁所以前面那条insert 语句会将那一行的隐式锁转行为X锁 所以后面的 select语句的 读锁 会和insert 语句生成的X锁冲突,所以select语句等待 如果select语句 不是 select * 全表记录 ,而是 select 其他的已存在索引上的等值记录,那么就不会和insert 语句X锁 冲突,则可以查询成功
隐式锁的逻辑过程如下
A. InnoDB目录页中的每条记录中都一个隐含的trx_id字段这个字段存在于聚簇索引的BTree中。
B. 在操作一条记录前首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务首先将隐式锁转换为显式锁 (就是为该事务添加一个锁)
C. 检查是否有锁冲突如果有冲突创建锁并设置为waiting状态。如果没有冲突不加锁跳到E。
D. 等待加锁成功被唤醒或者超时
E. 写数据并将自己的trx_id写入trx_id字段
如何判断隐式锁是否存在
InnoDB的每条记录中都一个隐含的trx_id字段这个字段存在于聚集索引的BTree中。假设只有主键索引则在进行插入时行数据的trx_id被设置为当前事务id假设存在二级索引则在对二级索引进行插入时需要更新所在page的max_trx_id。
因此对于主键只需要通过查看记录隐藏列trx_id是否是活跃事务就可以判断隐式锁是否存在。 对于对于二级索引会相对比较麻烦先通过二级索引页上的max_trx_id进行过滤如果无法判断是否活跃则需要通过应用undo日志回溯老版本数据才能进行准确的判断。
②显式锁
通过特定的语句进行加锁例如
#显示加共享锁
select .... lock in share mode
#显示加排它锁
select .... for update
其它锁
全局锁
就是对整个数据库实例 加锁。当你需要让整个库处于 只读状态 的时候可以使用这个命令之后其他线程的以下语句会被阻塞数据更新语句数据的增删改、数据定义语句包括建表、修改表结构等和更新类事务的提交语句-全局锁的典型使用 场景 是做 全库逻辑备份
Flush tables with read lock
死锁
死锁是指两个或多个事务在同一资源上相互占用并请求锁定对方占用的资源从而导致恶性循环。
有 两种解决策略 直接进入等待直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout 来设置 另一种策略是发起死锁检测发现死锁后主动回滚死锁链条中的某一个事务将持有最少行级排他锁的事务进行回滚让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on表示开启这个逻辑
