高性能Mysql(2)-锁和事务

1.并发控制

1.1锁的类型:

共享锁(shared lock)也叫读锁(read lock),排它锁(exclusive lock) 也叫写锁(write lock),读锁是共享的,相互不阻塞的,而写锁是阻塞的,写锁的优先级要高于读锁。

1.2锁的策略:

表锁:表锁是Mysql中最基本的锁的策略,并且是开销最小的策略。当用户对表进行操作的时候,它会锁定整张表。
行锁:行锁可以在最大程度上解决并发问题,但是也带来了最大的锁开销。

1.3死锁

死锁是指两个或者多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环。当多个事务试图以不同的顺序锁定资源的时候,就可能产生死锁,当多个事务锁定同一资源的时候也会产生死锁。

事务1:
start transaction;
update table set age=45 where id =3;
update table set age=20 where id =4;
commit;

事务2
start transaction ;
update table set age=13 where id =4;
update table set age=24 where id =3;
commit;

上面这种情况就是典型的死锁案例。

1.4多版本并发控制(*)

上述的锁是存储引擎默认实现的,而在真实的开发环境中,最常用的就是乐观锁和悲观锁,这是两种问题的解决方案。
更新丢失问题,更新丢失问题即多个线程同时基于同一个查询结果进行操作,后执行的操作将先进行的操作覆盖掉了。

+----+--------+------+----- +
| id | name | money|  status|
+----+--------+------+----- +
|  1 |  张三 | 1000 |   0    |
+----+--------+------+----- +

假设需要给张三转账100元转账完成后将status设置为1,证明已经转过帐就不再执行转账操作。

1.select status from order where id =1;//等于0则操作
2.update  order set money=money+100 and status=1 where id=1 ;

这时假如有多个线程同时操作这条sql就会产生上述的丢失更新问题。要就解决丢失更新的问题有两种方案。

悲观锁(*)

悲观的认为每次操作都会产生丢失更新问题,要使用悲观锁策略我们必须进行显式的锁定,因为在mysql中默认的采用的是autocommit模式,也就是说如果不是显式的开启一个事务,则每个查询操作都会当作一个事务提交。

start transction;
1.select status from order where id =1 for update;//等于0则操作
2.update  order set money=money+100 and status=1 where id=1 ;
commit;

此时mysql会将id为1的这一行数据锁定,直到更新完成才会释放锁。
注意:MySQL InnoDB默认Row-Level Lock,但是只有「明确」地指定主键,MySQL 才会执行Row lock (只锁住被选取的数据) ,否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。

乐观锁(*)

乐观的认为每次操作不会产生丢失更新问题,在表中增加一个版本控制字段进行控制。

update order set money=money+100 and version =version+1 where id=1 and version=0;

乐观锁和悲观锁没有绝对的好坏,我们应该根据具体的场景选用不同的解决方式。

2.事物

事务的是什么就不做阐述了

2.1事务的四个特新(ACID)

  • 原子性:一个事务必须是一个不可再分的最小的工作单元,在整个事务中操作要么全部成功要么全不成功。
  • 一致性: 数据库总是从一个一致性状态到另一个一致性状态,最终没有提交的数据不会保存到数据库中。
  • 隔离性: 一个事务在提交之前对其他事务是不可见的
  • 持久性: 一旦事务提交则其修改的数据就永久的保存在数据库中

2.2事务的隔离级别

  • read uncommited(未提交读) 会发生脏读
  • read commited(提交读) 可以解决脏读,可能会发生不可重复读
  • repeatable read (可重复读) 会产生幻读
  • serializable (串行化) 一般不用

2.3Mysql中的事务

mysql中默认的采用的是autocommit模式,也就是说如果不是显式的开启一个事务,则每个查询操作都会当作一个事务提交。可以通过设置autocommit开启或者禁用自动提交模式。1代表启用,0代表关闭。

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

推荐阅读更多精彩内容