MySQL锁与事务隔离级别
一、概述
1、锁的定义
锁是计算机协调多个进程或线程并发访问某一资源的机制。
在数据库中,除了传统的计算资源(如CPU、RAM、IO等)的争用以外,数据也是一种供需要用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题,锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说,锁对数据库而言显得尤其重要,也更加复杂。
2、锁的分类
- 从性能上分为乐观锁和悲观锁
乐观锁:每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。
例子:① 在数据库的表中加一个version字段,用来记录每次修改数据的版本号,防止并发修改数据出错;② CAS原子类。
悲观锁:每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到锁。
例子:synchronized关键字。
- 从对数据库操作的类型分为读锁和写锁(都属于悲观锁)
读锁(共享锁):针对同一份数据,多个读操作可以同时进行而不会互相影响。
写锁(排它锁):当前写操作没有完成前,它会阻断其他session的写锁和读锁。(session:数据库连接)
- 从对数据操作的粒度分为表锁和行锁。
二、表锁与行锁
1、表锁(偏读)
表锁偏向MyISAM存储引擎,开销小,加锁快,无死锁,锁定粒度大,发生锁冲突的概率最高,并发度最低。
(1)基本操作
- 建表SQL
CREATE TABLE `mylock` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键id',
`name` varchar(20) DEFAULT NULL COMMENT '名称',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8
- 插入数据
insert into `mylock` (`id`, `name`) values('1','a');
insert into `mylock` (`id`, `name`) values('2','b');
insert into `mylock` (`id`, `name`) values('3','c');
insert into `mylock` (`id`, `name`) values('4','d');
- 手动增加表锁
lock table 表名称 read(write), 表名称2 read(write)
- 查看表上过的锁
show open tables
- 删除表锁
unlock tables
(2)案例分析(加读锁)
当前session和其他session都可以读该表。
当前session中插入或者更新锁定的表都会报错,其他session插入或更新则会等待。
(3)案例分析(加写锁)
当前session对该表的增删改查都没问题,其他session对该表的索引操作被阻塞。
(4)案例结论
MyISAM在执行查询语句前,会自动给涉及的所有表加读锁,在执行增删改操作前,会自动给涉及的表加写锁。
① 对MyISAM表的读操作(加读锁),不会阻塞其他进程对同一表的读请求,但会阻塞对同一表的写请求。只有当读锁释放后,才会执行其他进程的写操作。
② 对MyISAM表的写操作(加写锁),会阻塞其他进程对同一表的读和写操作,只有当写锁释放后,才会执行其他进程的读写操作。
总结:读锁会阻塞写,但不会阻塞读。而写锁会阻塞读和写。
2、行锁(偏写)
行锁偏向InnoDB存储引擎,开销大,加锁慢,会出现死锁,锁定粒度最小,发生锁冲突的概率最低,并发度也最高。InnoDB和MYISAM的最大不同有两点:① 支持事务;② 采用了行级锁。
(1)行锁支持事务
- 事务(Transaction)及其ACID属性
事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。
原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全部执都执行,要么全都不执行。
一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性;事务结束时,所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。
隔离性(Isolation):数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。
持久性(Durable):事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。
- 并发事务处理带来的问题
(温馨提示:以下部分理论解释看不懂没关系,接着往下看,有例子)
更新丢失(Lost Update):当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题-最后的更新覆盖了由其他事务所做的更新。(可以用类似乐观锁的方案解决)
脏读(Dirty Reads):一个事务正在对一条记录做修改,在这个事务完成并提交前,这条记录的数据就处于不一致的状态;这时,另一个事务也来读取同一条记录,如果不加控制,第二个事务读取了这些“脏”数据,并据此做进一步的处理,就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。
一句话:事务A读取到了事务B已经修改但尚未提交的数据,还在这个数据基础上做了操作。此时,如果B事务回滚,A读取的数据无效,不符合一致性的要求。
不可重复读(Non-Repeatable Reads):一个事务在读取某些数据后的某个时间,再次读取以前读过的数据,却发现其读出的数据已经发生了改变、或某些记录已经被删除了!这种现象就叫做“不可重复读”。
一句话:事务A读取到了事务B已经提交的修改数据,不符合隔离性。
幻读(Phantom Reads):一个事务按相同的查询条件重新读取以前检索过的数据,却发现其他事务插入了满足其查询条件的新数据,这种现象就称为“幻读”。
一句话:事务A读取到了事务B已经提交的新增数据,不符合隔离性。
- 事务的隔离级别
“脏读”、“不可重复读”、“幻读”,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决。
数据库的事务隔离级别越严格,并发副作用越小,但付出的性能代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。
查看当前数据的事务隔离级别:show variables like 'tx_isolation'
设置事务隔离级别:set tx_isolation='REPEATABLE-READ'
MySQL默认的隔离级别是可重复读。
(2)行锁案例分析
- 用下面的表演示,需要开启事务,session_1更新某一行,session_2同时更新某一行将被阻塞,但是更新其他行正常
(3)隔离级别案例分析
CREATE TABLE `account` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键id',
`name` varchar(255) DEFAULT NULL COMMENT '名称',
`balance` int(11) DEFAULT NULL COMMENT '金额',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
insert into `account` (`id`, `name`, `balance`) values('1','lilei','450');
insert into `account` (`id`, `name`, `balance`) values('2','hanmei','16000');
insert into `account` (`id`, `name`, `balance`) values('3','lucy','2400');
① 读未提交:
a. 打开一个客户端A,并设置当前事务隔离级别为read uncommitted(读未提交),set tx_isolation='read-uncommitted',查询account表的初始值:
b. 在客户端A的事务提交之前,打开另一个客户端B,并设置当前事务隔离级别为read uncommitted,更新account表:
c. 这时,虽然客户端B的事务还没提交,但是客户端A就可以查询到B已经更新的数据:
d. 一旦客户端B的事务因为某种原因回滚,所有的操作都将会被撤销,那客户端A查询到的数据其实就是脏数据:
e. 脏数据展现:在客户端A执行更新语句update account set balance=balance-50 where id=1,lilei的balance没有变成350,而是400,数据不一致,因为在这过程中,并不知道客户端B会话回滚了,行数据实际上是450,450-50=400,可以采用读已提交的隔离级别。
② 读已提交:
a. 打开一个客户端A,并设置当前事务隔离级别为read committed(读已提交),set tx_isolation='read-committed',查询account表的初始值:
b. 在客户端A的事务提交之前,打开另一个客户端B,并设置当前事务隔离级别为read committed,更新account表:
c. 这时,客户端B的事务还没提交,客户端A不能查询到B已经更新的数据,解决了脏读的问题:
d. 客户端B的事务提交:
e. 客户端A执行与上一步相同的查询,结果与上一步不一致,即产生了不可重复读的问题。
③ 可重复读
a. 打开一个客户端A,并设置当前事务隔离级别为repeatable read(可重复读),set tx_isolation='repeatable-read',查询account表的初始值:
b. 在客户端A的事务提交之前,打开另一个客户端B,并设置当前事务隔离级别为repeatable read,更新account表:
c. 在客户端A查询account表的所有记录,与步骤a的查询结果一致,没有出现不可重复读的问题。
d. 在客户端A执行update account set balance=balance-50 where id=1,balance没有变成350-50=300,lilei的balance值用的是步骤b中的300来算的,所以是250,数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC机制,select操作不会更新版本号,是快照读(历史版本);insert、update和delete会更新版本号,是当前读(当前版本)。
e. 重新打开客户端B,插入一条新数据后提交:
f. 在客户端A查询account表的所有记录,没有查出新增数据,所以没有出现幻读:
g. 验证幻读:在客户端A执行update account set balance=666 where id=4;能更新成功,再次查询能查到客户端B新增的数据:
④ 串行化
a. 打开一个客户端A,并设置当前事务隔离级别为serializable(串行化),set tx_isolation='serializable',查询account表的初始值:
b. 打开一个客户端B,并设置当前事务隔离级别为serializable,插入一条记录报错,表被锁了插入失败,MySQL中事务隔离级别为serializable时会锁表,因此不会出现幻读的情况,但这种隔离级别并发性能极低,开发中很少会用到。
提问:MySQL默认级别是repeatable-read,有办法解决幻读问题吗?
间隙锁在某些情况下可以解决幻读问题。要避免幻读可以用间隙锁在session_1下面执行update account set name='Zeki' where id>3 and id<=20,则其他session没法插入这个范围内的数据。
InnoDB的行锁是针对索引加的锁,不是针对记录加的锁。并且该索引不能失效,否则都会从行锁升级为表锁。
无索引行锁升级为表锁:varchar如果不加 ' ',将导致系统自动转换类型,行锁变表锁,例如:update table set name=Zeki where id=1,这个语句会导致行锁变表锁,其他session无法对这个表做操作,5.7之后的版本这样写SQL会报错。
锁定某一行还可以用lock in share mode(共享锁)和for update(排他锁),例如:select * from table where id=1 for update,这样其他session只能读这行数据,修改则会被阻塞,直到锁定行的session提交。
(4)案例结论
InnoDB存储引擎由于实现了行级锁定,虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一下,但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量高的时候,InnoDB的整体性能和MyISAM相比就会有比较明显的优势了。但是,InnoDB的行级锁同样也有其脆弱的一面,当我们使用不当的时候,可能会让InnoDB的整体性能表现不仅不能比MyISAM高,甚至可能会更差。
(5)行锁分析
通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况:show status like 'innodb_row_lock%'。
(6)死锁
set tx_isolation='repeatable-read';
session_1执行:select * from account where id=1 for update;
session_2执行:select * from account where id=2 for update;
session_1执行:select * from account where id=2 for update;
session_2执行:select * from account where id=1 for update;
查看近期死锁日志信息:show engine innodb status\G。
大多数情况MySQL可以自动检查死锁并回滚产生死锁的那个事务,但是有些情况MySQL无法自动检测死锁。
(7)优化建议
- 尽可能让所有数据检索都通过索引来完成,避免无索引行锁升级为表锁
- 合理设计索引,尽量缩小锁的范围
- 尽可能减少检索条件,避免间隙锁
- 尽量控制事务大小,减少锁定资源量和时间长度
- 尽可能降低事务隔离级别
MySQL锁与事务隔离级别的更多相关文章
- 面试必问的MySQL锁与事务隔离级别
之前多篇文章从mysql的底层结构分析.sql语句的分析器以及sql从优化底层分析, 还有工作中常用的sql优化小知识点.面试各大互联网公司必问的mysql锁和事务隔离级别,这篇文章给你打神助攻,一飞 ...
- MySql锁和事务隔离级别
在讲mysql事物隔离级别之前,我们先简单说说mysql的锁和事务. 一:数据库锁 因为数据库要解决并发控制问题.在同一时刻,可能会有多个客户端对同一张表进行操作,比如有的在读取该行数据,其他的尝试去 ...
- 【MySQL】深入理解MySQL锁和事务隔离级别
先看个小案例: 话不多说,上案例,先创建一个表 mysql> CREATE TABLE IF NOT EXISTS `account`( `id` INT UNSIGNED AUTO_INCRE ...
- 深入理解mysql锁与事务隔离级别
一.锁 1.锁的定义 锁即是一种用来协调多线程或进程并发使用同一共享资源的机制 2.锁的分类 从性能上分类:乐观锁和悲观锁 从数据库操作类型上分类:读锁和写锁 从操作粒度上分类:表锁和行锁 2 ...
- 谈谈MySQL支持的事务隔离级别,以及悲观锁和乐观锁的原理和应用场景?
在日常开发中,尤其是业务开发,少不了利用 Java 对数据库进行基本的增删改查等数据操作,这也是 Java 工程师的必备技能之一.做好数据操作,不仅仅需要对 Java 语言相关框架的掌握,更需要对各种 ...
- 第36讲 谈谈MySQL支持的事务隔离级别,以及悲观锁和乐观锁的原理和应用场景
在日常开发中,尤其是业务开发,少不了利用 Java 对数据库进行基本的增删改查等数据操作,这也是 Java 工程师的必备技能之一.做好数据操作,不仅仅需要对 Java 语言相关框架的掌握,更需要对各种 ...
- mysql中不同事务隔离级别下数据的显示效果--转载
事务是一组原子性的SQL查询语句,也可以被看做一个工作单元.如果数据库引擎能够成功地对数据库应用所有的查询语句,它就会执行所有查询,如果任何一条查询语句因为崩溃或其他原因而无法执行,那么所有的语句就都 ...
- 浅谈mysql中不同事务隔离级别下数据的显示效果
事务的概念 事 务是一组原子性的SQL查询语句,也可以被看做一个工作单元.如果数据库引擎能够成功地对数据库应用所有的查询语句,它就会执行所有查询,如果任何一条查 询语句因为崩溃或其他原因而无法执行,那 ...
- 事务,Oracle,MySQL及Spring事务隔离级别
一.什么是事务: 事务逻辑上的一组操作,组成这组操作的各个逻辑单元,要么一起成功,要么一起失败. 二.事务特性(4种): 原子性 (atomicity):强调事务的不可分割:一致性 (consiste ...
随机推荐
- 创建dynamics CRM client-side (十四) - Web API
Xrm.WebApi 是我们做前端开发不可不缺少的内容. Xrm.WebApi 分为online和offline online: 可以实现和服务器的CRUD交互 offline: 多用于mobile ...
- [集训]FWT基础练习题
题意 给出n个长度为20的二进制数和数字k,每次询问给出一个二进制数,问从n个数中挑k个数(不能重复)的按位或能包含询问的组合有多少个.数字均小于等于5E5,1s. 思考 强行算出2^20个答案,再O ...
- 尼姆博弈+SG函数
博弈这个东西真的很费脑诶.. 尼姆博奕(Nim Game):游戏者轮流从一堆棋子(或者任何道具)中取走一个或者多个,最后不能再取的就是输家.当指定相应数量时,一堆这样的棋子称作一个尼姆堆 当n堆棋子的 ...
- Leetcode 题目整理-2 Reverse Integer && String to Integer
今天的两道题关于基本数据类型的探讨,估计也是要考虑各种情况,要细致学习 7. Reverse Integer Reverse digits of an integer. Example1: x = 1 ...
- CentOS 7 上安装 Django 2.2.4,解决报错:No module named ‘_sqlite3′
1.首先下载最新版的sqlite :https://www.sqlite.org/download.html 下载源码包: 配置和编译方法如下: ./configure --prefix=/usr/l ...
- Arduino系列之DHT11模块采集数据(一)
下面我将介绍DHT11模块的相关用法 DHT11数字传感器概述:是一款含有已校准数字信号输出的温湿度复合传感器 .它应用专用的数字模块采集技术和温湿度传感技术 ,确保产品具有极 高的可靠性与卓越的长期 ...
- 看完这篇文章,再次遇到Jedis「Redis客户端」异常相信你不再怕了!
本文导读: [1] 疫情当前 [2] 应用异常监控 [3] Redis客户端异常分析 [4] Redis客户端问题引导分析 [5] 站在Redis客户端视角分析 [6] 站在Redis服务端视角分析 ...
- LinearLayout中组件右对齐
在LinearLayout中,如果将其定位方向设为横向排列:android:orientation="horizontal",那么这个布局中的控件将自左向右排列. 但有时会有这样的 ...
- 未来JDK中将不再包含JDBC-ODBC桥
今天才发现一个重要问题,java中居然没有这个桥了.让初学者真的泪流了! 甲骨文公司主要技术人员.JDBC规范领导者Lance Andersen今天在博客中称,从Java SE 8(java 1.8版 ...
- 题解 SP1716 【GSS3 - Can you answer these queries III】
\[ Preface \] 没有 Preface. \[ Description \] 维护一个长度为 \(n\) 的数列 \(A\) ,需要支持以下操作: 0 x y 将 \(A_x\) 改为 \( ...