mysql-并发控制

读写锁

读锁:共享锁,
写锁:排他锁,阻止其他的读锁和写锁行为

锁粒度

在锁机制存在的情况下,提高共享资源并发性的方法是让锁定对象更准确。尽量只锁定需要修改的数据部分。理想的情况下,精确锁定会修改的数据片段。
另一方面,加锁也需要消耗资源。锁的各种操作,包括获得锁、检查锁是否已解除、释放锁等,都会增加系统开销。如果锁的操作比较频繁,系统会花大量的时间来管理锁,如不是执行数据存储,则兄台那个的性能也会受到影响。
可见,锁管理的实现对性能指标存在着相互冲突的正反影响,将锁粒度固定在某个级别,可以实现锁管理的灵活性、系统消耗两方面的综合考虑。表锁、行级锁是比较常见、重要的锁策略。

  • 表锁
    用户在对表进行写操作前,需获得写锁,如果是写锁是行级锁,则会阻塞其他用户对该表的所有读写操作。
    尽管存储引擎可以管理自己的锁,MySQL本身还是会使用各种有效的表锁来实现不同的目的。例如ALTER TABLE语句的执行会触发表锁,而忽略存储引擎的锁机制。

  • 行级锁

事务

一组原子性的操作。ACID概念。

  • 原子性(atomicity):最小工作单元,要么都成功,要么都失败。
  • 一致性(consistency):从一个一致性的状态转到另外一个一致性的状态,从原子性理解,事务的操作不会部分成功,部分失败,因此不会对系统数据造成不一致
  • 隔离性(isolation):通常来说,事务在最终提交前,对其他事务是不可见的。事务执行的部分对数据的变更对其他事务屏蔽。
  • 持久性(durability):一旦事务提交,所执行的修改会永久的保存到数据库中

隔离级别

SQL标准中定义了4中隔离级别,低级别的隔离可以执行更高的并发,系统的开销也更低。

  • READ UNCOMMITTED(未提交读)该隔离级别下,事务中的修改,即使没有提交,对其他事务也都是可见的。因此,对于其他业务,可能会产生“脏读”(读取到部分修改的、事务未提交的数据),从而引起很多问题。同时从性能层面考虑,
  • READ UNCOMMITED 和其他隔离级别也差不多,因此实际场景中一般很少使用。脏读:事务T1更新了一行记录的内容,但是并没有提交所做的修改。事务T2读取更新后的行,然后T1执行回滚操作,取消了刚才所做的修改。现在T2所读取的行就无效了
  • READ COMMITTED(提交读)大多数据库的默认隔离级别,但MySQL不是。本隔离级别下,满足隔离的基本定义:事务在提交前所做的修改对其他业务不可见。该级别下,两次执行同样的查询,可能会得到不一样的结果,产生不可重复读的效果。不可重复读:事务T1读取一行记录,紧接着事务T2修改 了T1刚才读取的那一行记录。然后T1又再次读取这行记录,发现与刚才读取的结果不同。这就称为“不可重复”读,因为T1原来读取的那行记录已经发生了变化。
  • REPEATABLE READ(可重复读)MySQL默认隔离级别。该隔离级别解决了不可重复读问题,但还是存在幻读。InnoDB 通过多版本并发控制(MVCC)解决幻读问题。幻读:事务T1读取一条指定的WHERE子句所返回的结果集。然后事务T2新插入 一行记录,这行记录恰好可以满足T1所使用的查询条件中的WHERE 子句的条件。然后T1又使用相同的查询再次对表进行检索,但是此时却看到了事务T2刚才插入的新行。这个新行就称为“幻像”,因为对T1来说这一行就像突然出现的一样。
    SERIALIZE(可串行化)它强制事务串行执行。该隔离级别下,会对读取的每一行数据上都加上锁。因而对锁机制的管理比较耗系统资源。
隔离级别 脏读可能性 不可重复读可能性 幻读可能性 加锁读
READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZE

死锁

在事务中混合使用存储引擎

MySQL服务器层不管理事务,事务是由存储引擎实现的。所以在同一个事务中,使用多个存储引擎是不可靠的。
具体为:在正常提交情况下不会有问题,但如果事务需要回滚,非事务型的表变更会无法撤销,从而导致数据库表数据不一致。

多版本并发控制

MVCC, 前面有提到。MySQL的大多数事务型存储引擎的实现都不是简单的行级锁。
MVCC 的实现,是通过保存数据在某个时间点的快照实现的。即不管需要执行多长时间,每个事务看到的数据都是一致的。根据事务开始的时间不同,每个事务对同一张表,同一时刻看到的数据可能是不一样的。
InnoDb 的 MVCC,是通过在每行记录后面保存两个隐藏的列来实现的。这两个列,一个保存了创建时间,一个保存行的过期时间(或删除时间)。当然存储的并不是实际的时间值,而是系统版本号。每开始一个新的事务,系统版本号都会自动增加。

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

推荐阅读更多精彩内容