mysql数据库的锁机制及事务特性

MyISAM和InnoDB关于锁方面的区别


首先我们来了解一下表锁行锁

MyISAM默认用表级锁,不支持行级锁
表级锁分为共享表锁(读锁)排他表锁(写锁)
当先执行某个语句时,会默认先上锁,有先后顺序,
1、当select将会加上读锁(在末尾加上for table也可以加上写锁)
2、update,insert,delete操作时会上写锁
3、lock tables 表名 read(write) 上读(写)锁


读锁时,同为读锁的操作也可以进行,而写锁操作不能进行
写锁时,同为写锁的操作也不可以进行,读锁行为也无法操作。

InnoDB支持行锁和表锁默认使用行锁,与MyISAM区别在于:

1、InnoDB只有通过索引条件检索数据才使用行级锁,否则,InnoDB将使用表锁(它的行锁基于索引

2、MyISAM可以支持查询和插入操作的并发进行。可以通过系统变量 concurrent_insert来指定哪种模式,它默认,如果MyISAM表中表的中间没有有被删除的行,那MyISAM允许在一个进程读表的同时,另一个进程从表尾插入记录。
但是InnoDB引擎是不支持的!

MyISAM与InnoDB适用场景

MyISAM
1、MyISAM适合频繁执行全表count(因为MyISAM有自带行数记录,InnoDB没有)
2、MyISAM适合对增删改的频率不高的数据,查询(select)频繁的(因为聚集索引+MVCC+事务所需要的维护比MyISAM多太多了

InnoDB
1、更适合增删改查频率高的数据(行锁只会锁操作行的值,而不是整张表)
2、安全性,可靠性要求高的数据(支持MVCC+事务

事务的四大特性


事务的四大特性简称ACID,分别是:
1、原子性(Atomic)用户包含的全部操作,要么一起操作,要么不操作
2、一致性(Consistency)应满足完整性约束
3、隔离性(Isolation)一个事务的执行不应该影响其他事务
4、持久性(Durability)保持数据永久修改

事务隔离级别对并发访问的影响以及MVCC


事务可以避免并发引起的问题,如:
更新丢失---Mysql已经可避免

脏读---一个事务读到另一个事务未提交(commit)的数据

不可重复读---一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。但是两次执行同样的查询,可能会得到不一样的结果。

幻读---并不是说两次读取获取的结果集不同,幻读侧重的方面是某一次的 select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些:select 某记录是否存在,不存在准备插入此记录,但执行 insert 时发现此记录已存在无法插入,此时就发生了幻读

关于幻读的理解,详情请参考https://segmentfault.com/a/1190000016566788
而隔离级别的解决方案,如下图

RR(可重复读)情况下使用MVCC(多版本并发控制)避免幻读


我们先来科普下当前读快照读

当前读:没什么好说的,其实就是前面所说的给语句加上读锁和写锁

快照读:就是非阻塞读,不加锁的select就是快照读

在表锁中我们读写是阻塞的,基于提升并发性能的考虑MVCC一般读写是不阻塞的(所以说MVCC很多情况下避免了加锁的操作)

MVCC实现的读写不阻塞正如其名:多版本并发控制--->通过一定机制生成一个数据请求时间点的一致性数据快照(Snapshot),并用这个快照来提供一定级别(语句级或事务级)的一致性读取。从用户的角度来看,好像是数据库可以提供同一数据的多个版本。

简单地说就是(如上图):当session1进行了一次select之后,session2进行了update修改了fieled3,那么undo日志会将语句会存入一个数据快照用于回滚,而session1再调用select语句的时候会创建一个read view(用来决定查看快照数据还是最新数据),查询的其实是快照数据,而非最新数据

间隙锁GAP


其实RR防止幻读本质是GAP

当我们用范围条件检索数据InnoDB引擎会给符合范围条件的已有数据记录的索引项加锁,一般我们称之为间隙锁(GAP)

!!间隙锁只会在 Repeatableread隔离级别下使用

对主键索引和唯一索引时,
where条件全部命中,则只会加记录锁
where条件未全部命中,就会加GAP锁

其他条件下,如:非唯一索引或者不走索引的当前读情况下
GAP锁无法精确定位范围

非唯一索引

它将会把指定位置的(6,9],(9,11]的区域锁定,根据叶子节点的顺序排列的值,如bd将会被上锁
不走索引

而不走索引的情况下,整张表将会被锁住

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 222,252评论 6 516
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 94,886评论 3 399
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 168,814评论 0 361
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,869评论 1 299
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,888评论 6 398
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 52,475评论 1 312
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 41,010评论 3 422
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,924评论 0 277
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 46,469评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,552评论 3 342
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,680评论 1 353
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 36,362评论 5 351
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 42,037评论 3 335
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,519评论 0 25
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,621评论 1 274
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 49,099评论 3 378
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,691评论 2 361

推荐阅读更多精彩内容

  • 1 MySQL的三种锁 1.1 表锁 开销小,加锁快 不会出现死锁 锁定粒度大,发生锁冲突的概率最高,并发度最低 ...
    JavaEdge阅读 657评论 0 1
  • 索引 数据库中的查询操作非常普遍,索引就是提升查找速度的一种手段 索引的类型 从数据结构角度分 1.B+索引:传统...
    一凡呀阅读 2,939评论 0 8
  • 事务可以用来维护数据库的完整性,保证成批的 SQL 语句要么全部执行,要么全部不执行。MySQL 中只有使用了 I...
    伊凡的一天阅读 2,373评论 3 22
  • MySQL中主要有两种锁:行级锁和表级锁:行级锁(row-level):特点是锁定对象的粒度小,发生锁定资源争用的...
    田真的架构人生阅读 819评论 0 1
  • 要写一个招募文,头发都要被抓秃了,还想不出什么新意来。 思维朝着背景,现状,冲突,应对等板块内容奔腾而去了,然而如...
    藏柳阅读 216评论 0 0