文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Mysql锁的内部实现机制是什么

2024-04-02 19:55

关注

这篇“Mysql锁的内部实现机制是什么”文章的知识点大部分人都不太理解,所以小编给大家总结了以下内容,内容详细,步骤清晰,具有一定的借鉴价值,希望大家阅读完这篇文章能有所收获,下面我们一起来看看这篇“Mysql锁的内部实现机制是什么”文章吧。

注:所列举代码皆出自Mysql-5.6

虽然现在关系型数据库越来越相似,但其背后的实现机制可能大相径庭。实际使用方面,因为SQL语法规范的存在使得我们熟悉多种关系型数据库并非难事,但是有多少种数据库可能就有多少种锁的实现方法。

Microsoft Sql Server2005之前只提供页锁,直到2005版本才开始支持乐观并发悲观并发,乐观模式下允许实现行级别锁,在Sql Server的设计中锁是一种稀缺资源,锁的数量越多,开销就越大,为了避免因为锁的数量快速攀升导致性能断崖式下跌,其支持一种称为锁升级的机制,一旦行锁升级为页锁,并发性能就又回到原点。

事实上,即使在同一个数据库,不同的执行引擎对锁这一功能的诠释依然是百家争鸣。对于MyISAM而言仅仅支持表锁,并发读取尚可,并发修改可就捉襟见肘了。Innodb则和Oracle非常相似,提供非锁定一致性读取行锁支持,与Sql Server明显不同的是随着锁总数的上升,Innodb仅仅只需要付出一点点代价。

行锁结构

Innodb支持行锁,且对于锁的描述并不会存在特别大的开销。因此不需要锁升级这一机制作为大量锁导致性能下降之后的抢救措施。

摘自lock0priv.h文件,Innodb对于行锁的定义如下:


struct lock_rec_t {
    
    ulint  space;	
    
    
    ulint  page_no;
    
    
    ulint  n_bits;			
};

不难看出虽然并发控制可以细化到行级别,但是锁以页的粒度组织管理。Innodb的设计中通过space id、page number两个必要条件就可以确定唯一一个数据页,n_bits表示描述该页行锁信息需要多少bit位。

同一数据页中每条记录都分配唯一的连续的递增序号:heap_no,若要知道某一行记录是否上锁,则只需要判断位图heap_no位置的数字是否为一即可。由于lock bitmap根据数据页的记录数量进行内存空间分配的,因此没有显式定义,且该页记录可能还会继续增加,因此预留了LOCK_PAGE_BITMAP_MARGIN大小的空间。


#define LOCK_PAGE_BITMAP_MARGIN	 64

假设space id = 20,page number = 100的数据页目前有160条记录,heap_no为2、3、4的记录已经被锁,则对应的lock_rec_t结构与数据页应该被这样刻画:

Mysql锁的内部实现机制是什么

注:

  • 内存中的lock bitmap应该是线性分布的,图中所示二维结构是为了方便描述

  • bitmap与lock_rec_t结构是一块连续内存,图中引用关系也是绘图需要

可以看到该页对应的bitmap第二三四位置全部置一,描述一个数据页行锁所消耗内存从感官上相当有限,那具体占用多少呢?我们可以计算一下:
160 / 8 + 8 + 1 = 29byte。

这里还额外+1,应该是为了避免因为整除导致的结果数值偏小的问题。假如是161条记录如果不+1则计算出来的20byte不够描述所有记录的锁信息(不动用预留位)。

摘自lock0priv.h文件:


n_bits = page_dir_get_n_heap(page) + LOCK_PAGE_BITMAP_MARGIN;
n_bytes = 1 + n_bits / 8;


lock = static_cast<lock_t*>(
    mem_heap_alloc(trx->lock.lock_heap, sizeof(lock_t) + n_bytes)
);



UNIV_INLINE ulint page_dir_get_n_heap(const page_t* page)	
{
    return(page_header_get_field(page, PAGE_N_HEAP) & 0x7fff);
}

表锁结构

Innodb还支持表锁,表锁可分为两大类:意向锁,自增锁其数据结构定义如下:

摘自lock0priv.h文件

struct lock_table_t {
    
    dict_table_t*  table;
    
    
    UT_LIST_NODE_T(lock_t)  locks;
};

摘自ut0lst.h文件

struct ut_list_node {
    
    TYPE*  prev;
    
    
    TYPE*  next;
};


#define UT_LIST_NODE_T(TYPE)  ut_list_node<TYPE>

事务中锁的描述

上述lock_rec_t、lock_table_t结构只是单独的定义,锁产生于事务之中,因此每个事务对应的行锁、表锁会有一个相应的锁的结构,其定义如下:

摘自lock0priv.h文件


struct lock_t {
    
    trx_t*  trx;
    
    
    UT_LIST_NODE_T(lock_t)  trx_locks;	
    
    
    ulint  type_mode;
    
    
    hash_node_t  hash;	
    
    
    dict_index_t*  index;
    
    
    union {
        
        lock_table_t  tab_lock;
        
        
        lock_rec_t  rec_lock;
    } un_member;
};

lock_t是根据每个事务每个页(或表)来定义的,但是一个事务往往涉及到多个页,因此需要链表trx_locks串联起一个事务相关的所有锁信息。除了需要根据事务查询到所有锁信息,实际场景还要求系统必须能够快速高效的检测出某个行记录是否已经上锁。因此必须有一个全局变量支持对行记录进行锁信息的查询。Innodb选择了哈希表,其定义如下:

摘自lock0lock.h文件


struct lock_sys_t {
    
    ib_mutex_t  mutex;		
    
    
    hash_table_t*  rec_hash;	
    
    
    ib_mutex_t  wait_mutex;
    
    
    srv_slot_t*  waiting_threads;
    
    
    srv_slot_t*  last_slot;
    
    
    ibool  rollback_complete;
		
    
    ulint  n_lock_max_wait_time;

    
    os_event_t	timeout_event;		

    
    bool  timeout_thread_active;
};

函数lock_sys_create在database start之际负责初始化lock_sys_t结构。rec_hash的hash slot数量由srv_lock_table_size变量决定。rec_hash哈希表的key值通过页的space id,page number计算得出。

摘自lock0lock.icut0rnd.ic 文件


UNIV_INLINE ulint lock_rec_fold(ulint space, ulint page_no)
{
    return(ut_fold_ulint_pair(space, page_no));
}



UNIV_INLINE ulint ut_fold_ulint_pair(ulint n1, ulint n2)
{
    return (
        (
            (((n1 ^ n2 ^ UT_HASH_RANDOM_MASK2) << 8) + n1)
            ^ UT_HASH_RANDOM_MASK
        ) 
        + n2
    );
}

这将意味着无法提供一个手段使得我们可以直接得知某一行是否上锁。而是应该先通过其所在的页得到space id、page number通过lock_rec_fold函数得出key值而后经过hash查询得到lock_rec_t,而后根据heap_no扫描bit map,最终确定锁信息。lock_rec_get_first函数实现了上述逻辑:

这里返回的其实是lock_t对象,摘自lock0lock.cc文件


UNIV_INLINE lock_t* lock_rec_get_first(const buf_block_t* block, ulint heap_no)
{
    lock_t*  lock;

    ut_ad(lock_mutex_own());

    for (lock = lock_rec_get_first_on_page(block); lock;
         lock = lock_rec_get_next_on_page(lock)
    ) {
        if (lock_rec_get_nth_bit(lock, heap_no)) {
            break;
        }
    }

    return(lock);
}

锁维护以页的粒度,不是一个最高效直接的方式,明显的时间换空间,这种设计使得锁的开销很小。某一事务对任一行上锁的开销都是一样的,锁数量的上升也不会带来额外的内存消耗。

每个事务都对应一个trx_t的内存对象,其中保存着该事务锁信息链表和正在等待的锁信息。因此存在如下两种途径对锁进行查询:

上述各种数据结构,对其整理关系如下图所示:

Mysql锁的内部实现机制是什么

注:

  • lock_sys_t中的slot颜色与lock_t颜色相同则表明lock_sys_t slot持有lock_t
    指针信息,实在是没法连线,不然图很混乱

以上就是关于“Mysql锁的内部实现机制是什么”这篇文章的内容,相信大家都有了一定的了解,希望小编分享的内容对大家有帮助,若想了解更多相关的知识内容,请关注亿速云行业资讯频道。

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯