产品中心
虽然现在关系型数据库越来越相似，但其背后的实现机制可能大相径庭。实际使用方面，因为SQL语法规范的存在使得我们熟悉多种关系型数据库并非难事，但是有多少种数据库可能就有多少种锁的实现方法。
Microsoft Sql Server2005之前只提供页锁，直到2005版本才开始支持乐观并发、悲观并发，乐观模式下允许实现行级别锁，在Sql Server的设计中锁是一种稀缺资源，锁的数量越多，开销就越大，为了避免因为锁的数量快速攀升导致性能断崖式下跌，其支持一种称为锁升级的机制，一旦行锁升级为页锁，并发性能就又回到原点。
事实上，即使在同一个数据库，不同的执行引擎对锁这一功能的诠释依然是百家争鸣。对于MyISAM而言仅仅支持表锁，并发读取尚可，并发修改可就捉襟见肘了。Innodb则和Oracle非常相似，提供非锁定一致性读取、行锁支持，与Sql Server明显不同的是随着锁总数的上升，Innodb仅仅只需要付出一点点代价。
Innodb支持行锁，且对于锁的描述并不会存在特别大的开销。因此不需要锁升级这一机制作为大量锁导致性能下降之后的抢救措施。
摘自lock0priv.h文件，Innodb对于行锁的定义如下：
注：
可以看到该页对应的bitmap第二三四位置全部置一，描述一个数据页行锁所消耗内存从感官上相当有限，那具体占用多少呢？我们可以计算一下:
160 / 8 + 8 + 1 = 29byte。
这里还额外+1，应该是为了避免因为整除导致的结果数值偏小的问题。假如是161条记录如果不+1则计算出来的20byte不够描述所有记录的锁信息(不动用预留位)。
摘自lock0priv.h文件:
注:
lock_sys_t中的slot颜色与lock_t颜色相同则表明lock_sys_t slot持有lock_t 指针信息，实在是没法连线，不然图很混乱
到此这篇关于Mysql锁内部实现机制之C源码解析的文章就介绍到这了,更多相关Mysql锁内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
