注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

风轻扬

活着就是为了追求幸福

 
 
 

日志

 
 
关于我

关注互联网应用架构、分布式与海量数据处理技术、云计算、数据库技术

网易考拉推荐

InnoDB加锁实现机制初步分析  

2011-01-07 16:04:40|  分类: MySQL |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
虽然普通的SELECT在InnoDB里是不需要加行锁的,但LOCK IN SHARE MODE、更新操作及高串行化级别中的SELECT都要加锁。InnoDB宣称其行锁实现非常先进,开销只有每行3-4 bit。传统的数据库锁表结构,锁定一条记录时要构建一个包含被锁定对象ID信息、等待者队列、持有者队列链接等一系列东东的复杂数据结构,开销至少在100字节以上。InnoDB竟然可以做到只有3-4 bit,真是牛到不可思议。

于是,去初步了解了一下。基本原理应该是像这篇日志里说的这样还是用的Hash的锁表,只不过不是锁一条记录就创建一个复杂的结构,而是用位图来表示页面中各记录的锁定情况,这样,一个事务锁定页面中的很多行时,只需要把很多个位置设为1就行了,事务锁定大量记录时的平均空间开销就会很小。上述日志里做了个测试,一个事务锁定过百万条记录时,确实锁表占用的空间大概只有每条记录3 bit。

据此推测,如果一个事务只锁定页面中的少量记录,那这个平均开销就大了,上述日志没做过这样的测试。我简单测试了一下,发现确实如此,如果只锁定一个页面中的一条记录的话,也会新建个lock struct,占用空间似乎过百字节。如果一个事务锁定属于同一页面的两条记录,则只有一个lock struct,如果锁定不属于同一页面的两条记录,则就会产生两个lock struct。另外一条记录如果被N个事务同步锁定,锁占用的空间似乎就会达到N倍。

这样看来InnoDB宣称的单记录锁定空间开销3-4 bit是不假,但只是在事务锁定连续的大量记录时才是这样,如果事务只是随机的锁定一些记录,这些记录分散在很多页面上,则单记录的平均开销就大了。基本上锁的空间开销取决于被锁定的页面数。

上述只是推测,要了解真知还得有空时分析代码。
  评论这张
 
阅读(2365)| 评论(3)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017