数据库锁(lock)

  看了两本书,一本是《高性能MySQL》,一本是《MySQL技术内幕——InnoDB存储引擎》,感觉要不写点什么,就白看了,本篇主要以MySQL的InnoDB为例,聊聊lock的相关东西

一、什么是lock

  锁是数据库系统区别于文件系统的一个关键性特征,锁机制用于管理对共享资源的并发访问,而lock主要是针对数据库中的对象,如表、页、行,并且一般lock的对象仅在事务commit或rollback后进行释放。

  对于InnoDB可以通过如下命令来观察锁的情况

    select * from information_schema.INNODB_TRX; #查看事务情况

    select * from information_schema.INNODB_LOCKS; #查看锁情况

    select * from information_schema.INNODB_LOCK_WAITS; #查看锁等待情况

二、InnoDB中lock的类型

InnoDB存储引擎实现了以下两种标准的行级锁

  共享锁(S Lock):也叫读锁,故名思议在读取的时候给数据对象加锁

  排他锁(X Lock):也叫写锁,为了避免并发写出现不可预知的后果,在修改数据对象的时候给数据加锁

  一个记录(row),可以同时拥有多个S锁,但是同时只能拥有一个X锁,X锁会阻塞其他线程对记录的操作,需要注意的是S锁和X锁都是行锁,兼容是指对同一记录(row)锁的兼容情况,下面有一个锁的兼容表

锁兼容示意图

三、一致性非锁定读

  什么是一致性非锁定读和一致性锁定读,他们各有什么优缺点,如何使用他们(显示或者隐身使用),他们跟其他那些东西还有什么样的关联,对其影响如何

  一致性非锁定读是指的是InnoDB存储引擎通过多版本控制(MVCC)的技术来读取行数据,就算被读取行正在执行更新和删除操作也不会被阻塞,相反地,InnoDB存储引擎会去读取行的一个快照数据。

  之所以叫做一致性非锁定读,是因为不需要等待访问行上的X锁的释放。非锁定读极大的提高了数据库的并发性能,在InnoDB存储引擎中默认的就是以这种方式读取,需要注意的是,不同的事务隔离级别下是否采用一致性非锁定读和快照数据的定义也都各不相同。

  在MySQL(其他的实现方式不一样,比如PostgreSQL)的InnoDB中,仅在 READ COMMITTED 和 REPEATABLE READ下使用MVCC,所以也仅在这两张隔离级别下才会使用一致性非锁定读。对于快照数据版本,在 READ COMMITTED 下总是读取被锁定行的最新的一份快照;而在 REPEATABLE READ 下总是读取事务开始时的行数据版本(不会出现幻读)

四、一致性锁定读

  有了上面一致性非锁定读的解释,相信一致性锁定读就更好理解,简单来说就是在读取行的时候不在允许其他用户对行进行修改和删除,也叫做不允许加排它锁

  在某些情况下,用户需要显示地对数据库读取操作进行加锁以保证数据逻辑一致性,这时候就需要用到手动加锁的情况,InnoDB提供了两种读取时手动加锁的方法如下

    SELECT ... FOR UPDATE

    SELECT ... LOCK IN SHARE MODE

  两个语句实现上是有一定区别的, FOR UPDATE 是对读取的行加一个X锁,而 LOCK IN SHARE MODE 对读取行加一个S锁。在使用的时候需要将语句放在事务中执行,一旦离开事务锁就会自动释放,当然为了防止死锁,时间长了数据库也会自动释放锁

  这里需要注意的是,在使用了MVCC的事务隔离级别下即便是加了X锁,其他用户也是可以读取数据的,只是读取的是对应快照数据。在 SERIALIZABLE 隔离级别下就可看到两个语句的不同,FOR UPDATE 会阻塞其他用户对行的读取,而 LOCK IN SHARE MODE 却不会。

五、锁的算法

InnoDB存储引擎有三种行锁算法:

  Record Lock:单个行记录上的锁

  Gap Lock:间隙锁,锁定一个范围,但不包含记录本身

  Next-Key Lock:Gap Lock + Record Lock,锁定一个范围,并且锁定记录本身

  InnoDB对于行的查询都使用了Next-Key Lock的算法,Record Lock比较好理解,Gap Lock要复杂点,因为InnoDB在索引、主键、事务隔离级别都会对其有一定的影响

1、条件查询单列,非索引
  此时当我们通过for update显示锁定某一行的时候,其实根据Next-Key Lock算法会采用间隙锁的方式,这时增加、删除、修改其他行都会被阻塞,其锁定的是(-∞,+∞)


单列无索引锁定区间示意图

2、条件查询单列,非唯一索引
  同上,存储引擎还是会使用Next-Key Lock的方式,不过这时锁定的不在是(-∞,+∞),而是锁定的我们指定行的前后区间,即(pre,x]和(x,next)。所以我们在操作pre和之前,以及next和之后的行都不会阻塞


单列非唯一索引锁定区间示意图

3、条件查询单列,唯一索引
  InnoDB对于这种情况会有特殊的优化,由于是唯一索引,所以没必要在指定锁定一行时使用间隙锁,这时候会降级使用Record Lock,仅锁住索引记录本身,需要注意主键也是唯一索引
4、条件查询多列,多索引
  这种情况其实就是取的一个并集,每个列对应索引锁定的区间合起来的并集
5、联合索引的问题
  这个在书中有特别提到,当一个唯一索引是联合索引时,但是查询条件仅是其中部分列的话,还是会使用Next-Key Lock
6、显示关闭使用Gap Lock
  可以通过修改事务隔离级别READ COMMITTED显示关闭
  通设置参数innodb_locks_unsafe_for_binlog=1
7、Next-Key Locking 与幻象问题
  Mysql中默认事务隔离级别下,即REPEATABLE READ下,InnoDB存储引擎采用Next-Key Locking机制就可以保证幻象问题,而不需要使用SERIALIZABLE隔离级别

五、阻塞、死锁

阻塞

  因为不同锁之间的兼容性关系,在有些时刻一个事务中的锁需要等待另外一个事务中的锁释放它所占用的资源。这就是阻塞,阻塞并不是一件坏事情,其实是为了确保事务可以并发且正常的运行,在InnoDB存储引擎中,有一些变量来控制等待的相关操作
  innodb_lock_wait_timeout:控制等待的时间(默认50秒)
  innodb_rollback_on_timeout:设定是否在等待超时时对进行中的事务进行回滚操作(默认是OFF,不回滚)

死锁

  死锁是指两个或两个以上的事务在执行过程中,因争夺锁资源而造成的一种互相等待的现象

如何解决死锁?
1、超时回滚
  当事务相互等待的时候,一个事务等待时间超过设置的阀值,就将其回滚,而另外的事务就能继续的进行
  缺点也是显而易见的,如果超时的事务所占权重比较大,如事务操作更新了很多行,占用了较多的undo log,这时显得就不合适了,因为回滚的这个事务的时间相对另外的事务所占时间可能会很多
2、wait-for garph(等待图)
  这是一种主动的死锁检查方式,InnoDB引擎也采用这种方式,在每个事务请求锁并发生等待时都会判断是否存在回路,若存在,通常来说InnoDB选择回滚undo量最小的事务,wait-for garph要求数据库保存两种信息,1、锁的信息链表;2、事务等待链表。通过这样的链表可以构造出一张图,而图中存在回路就代表存在死锁。

影响死锁概率的因素
1、系统中事务的数量,越多发生死锁概率越大
2、每个事务操作的数量,操作数量越多,概率越大
3、操作数据的集合,越小发生死锁概率越大

六、基于锁的并发思考

扩展阅读
关于MySQL/InnoDB的加锁规则扩展阅读,作者分析的很透彻
http://hedengcheng.com/?p=771

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

推荐阅读更多精彩内容