1 表锁(偏读)
表锁偏向MyISAM存储引擎,开销小,加锁快,无思索,锁定粒度大,发生锁冲突的概率最高,并发度最低。
行锁偏向InnoDB存储引擎,开销大,加锁慢,会出现死锁,锁定粒度最小,发生锁冲突的概率最低,并发度也最高。InnoDB与MYISAM的最大不同有两点:一是支持事务(TRANSACTION);二是采用了行级锁。
2 行锁(偏写)
行锁在 InnoDB 中是基于索引实现的,所以一旦某个加锁操作没有使用索引,那么该锁就会退化为表锁。
2.1 行锁支持事务
1 事务(Transaction)及其ACID属性
事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。
原子性(Atomicity) :事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。
一致性(Consistent) :在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性;事务结束时,所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。
隔离性(Isolation) :数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。
持久性(Durable) :事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。
2 并发事务处理带来的问题
更新丢失(Lost Update)
当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题–最后的更新覆盖了由其他事务所做的更新。
脏读(Dirty Reads)
一个事务正在对一条记录做修改,在这个事务完成并提交前,这条记录的数据就处于不一致的状态;这时,另一个事务也来读取同一条记录,如果不加控制,第二个事务读取了这些“脏”数据,并据此作进一步的处理,就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。
一句话:事务A读取到了事务B已经修改但尚未提交的数据,还在这个数据基础上做了操作。此时,如果B事务回滚,A读取的数据无效,不符合一致性要求。
不可重读(Non-Repeatable Reads)
一个事务在读取某些数据后的某个时间,再次读取以前读过的数据,却发现其读出的数据已经发生了改变、或某些记录已经被删除了!这种现象就叫做“不可重复读”。
一句话:事务A读取到了事务B已经提交的修改数据,不符合隔离性
幻读(Phantom Reads)
一个事务按相同的查询条件重新读取以前检索过的数据,却发现其他事务插入了满足其查询条件的新数据,这种现象就称为“幻读”。
一句话:事务A读取到了事务B提交的新增数据,不符合隔离性
脏读是事务B里面修改了数据
幻读是事务B里面新增了数据
3 事务隔离级别
脏读”、“不可重复读”和“幻读”,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决。
数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。
同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不敏感,可能更关心数据并发访问的能力。
常看当前数据库的事务隔离级别: show variables like 'tx_isolation';
设置事务隔离级别:set tx_isolation='REPEATABLE-READ';
4 行锁分析
通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况
show status like'innodb_row_lock%';
对各个状态量的说明如下:
Innodb_row_lock_current_waits: 当前正在等待锁定的数量
Innodb_row_lock_time: 从系统启动到现在锁定总时间长度
Innodb_row_lock_time_avg: 每次等待所花平均时间
Innodb_row_lock_time_max:从系统启动后统启动到现在等待最长的一次所花时间
Innodb_row_lock_waits:系到现在总共等待的次数
对于这5个状态变量,比较重要的主要是:
Innodb_row_lock_time_avg (等待平均时长)
Innodb_row_lock_waits (等待总次数)
Innodb_row_lock_time(等待总时长)
查看近期死锁日志信息:show engine innodb status\G;
3 mysql锁类型
3.1记录锁(Record Locks)
顾名思义,记录锁就是为某行记录加锁,它封锁该行的索引记录
:
-- id 列为主键列或唯一索引列
SELECT * FROM table WHERE id = 1 FOR UPDATE;
复制代码
id 为 1 的记录行会被锁住。
需要注意的是:id
列必须为唯一索引列
或主键列
,否则上述语句加的锁就会变成临键锁
。
同时查询语句必须为精准匹配
(=
),不能为 >
、<
、like
等,否则也会退化成临键锁
其他实现
在通过 主键索引
与 唯一索引
对数据行进行 UPDATE 操作时,也会对该行数据加记录锁
:
-- id 列为主键列或唯一索引列
UPDATE SET age = 50 WHERE id = 1;
复制代码
间隙锁(Gap Locks)
间隙锁基于非唯一索引
,它锁定一段范围内的索引记录
。间隙锁基于下面将会提到的Next-Key Locking
算法,请务必牢记:使用间隙锁锁住的是一个区间,而不仅仅是这个区间中的每一条数据。
SELECT * FROM table WHERE id BETWEN 1 AND 10 FOR UPDATE;
复制代码
即所有在(1,10)
区间内的记录行都会被锁住,所有id 为 2、3、4、5、6、7、8、9 的数据行的插入会被阻塞,但是 1 和 10 两条记录行并不会被锁住。
除了手动加锁外,在执行完某些 SQL 后,InnoDB 也会自动加间隙锁,这个我们在下面会提到。
临键锁(Next-Key Locks)
Next-Key 可以理解为一种特殊的间隙锁,也可以理解为一种特殊的算法。通过临建锁可以解决幻读
的问题。 每个数据行上的非唯一索引列
上都会存在一把临键锁,当某个事务持有该数据行的临键锁时,会锁住一段左开右闭区间的数据。需要强调的一点是,InnoDB
中行级锁
是基于索引实现的,临键锁只与非唯一索引列
有关,在唯一索引列
(包括主键列
)上不存在临键锁。
假设有如下表:
MySql,InnoDB,Repeatable-Read:table(id PK, age KEY, name)
id | age | name |
---|---|---|
1 | 10 | Lee |
3 | 24 | Soraka |
5 | 32 | Zed |
7 | 45 | Talon |
该表中 age
列潜在的临键锁
有:
(-∞, 10],
(10, 24],
(24, 32],
(32, 45],
(45, +∞],
在事务 A
中执行如下命令:
-- 根据非唯一索引列 UPDATE 某条记录
UPDATE table SET name = Vladimir WHERE age = 24;
-- 或根据非唯一索引列 锁住某条记录
SELECT * FROM table WHERE age = 24 FOR UPDATE;
复制代码
不管执行了上述 SQL 中的哪一句,之后如果在事务 B
中执行以下命令,则该命令会被阻塞:
INSERT INTO table VALUES(100, 26, 'Ezreal');
复制代码
很明显,事务 A
在对 age
为 24 的列进行 UPDATE 操作的同时,也获取了 (24, 32]
这个区间内的临键锁。
不仅如此,在执行以下 SQL 时,也会陷入阻塞等待:
INSERT INTO table VALUES(100, 30, 'Ezreal');
复制代码
那最终我们就可以得知,在根据非唯一索引
对记录行进行 UPDATE \ FOR UPDATE \ LOCK IN SHARE MODE
操作时,InnoDB 会获取该记录行的 临键锁
,并同时获取该记录行下一个区间的间隙锁
。
即事务 A
在执行了上述的 SQL 后,最终被锁住的记录区间为 (10, 32)
。
总结
- InnoDB 中的
行锁
的实现依赖于索引
,一旦某个加锁操作没有使用到索引,那么该锁就会退化为表锁
。 - 记录锁存在于包括
主键索引
在内的唯一索引
中,锁定单条索引记录。 - 间隙锁存在于
非唯一索引
中,锁定开区间
范围内的一段间隔,它是基于临键锁实现的。 - 临键锁存在于
非唯一索引
中,该类型的每条记录的索引上都存在这种锁,它是一种特殊的间隙锁,锁定一段左开右闭
的索引区间。
4. 查询mysql锁及事物的常用sql
4.1 查询数据库中的锁
select * from information_schema.innodb_locks;
4.2 查询锁等待信息
select * from information_schema.innodb_locks_waits;
4.3 查询事物信息
select * from information_schema.innodb_trx;
4.4 查询锁信息
show variables like '%innodb_lock%'
部分内容来源如下:
作者:Gtaker
链接:https://juejin.im/post/5b8577c26fb9a01a143fe04e
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。