关于 mysql 的页锁 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
Cyshall
V2EX    程序员

关于 mysql 的页锁

  •  
  •   Cyshall 2020-12-16 16:06:30 +08:00 2103 次点击
    这是一个创建于 1765 天前的主题,其中的信息可能已经有所发展或是发生改变。

    各位,问个关于 mysql 页锁的问题。

    首先页这个概念在 mysql 中有两处地方会出现,一个是 innodb 引擎中磁盘管理的最小单位,一个就是页锁,这两个地方的页是一个概念吗?

    如果是的话,又产生了另外一个问题:首先页锁的粒度是在表锁和行锁之间的(行锁<页锁<表锁),但是页的大小是 16KB,一张表如果只存一行数据明显不可能大于页,那是不是可以理解在这种情况下表锁的粒度要小于页锁?(或者这里的粒度大小不是按照数据大小来的?)

    其次,innodb 中的页相较于页锁中的页感觉抽象层次更低,也就是说完全是不同层次的概念了,毕竟 innodb 中的页是存数据的地方了(我知道 mysql 下面还有文件系统,文件系统中也有页的概念,这里只提 mysql )。 真的很迷惑,不知道有没有老哥可以解答一下。

    8 条回复    2020-12-17 11:21:59 +08:00
    xsm1890
        1
    xsm1890  
       2020-12-16 17:22:31 +08:00   2
    1.一张表如果只存一行数据明显不可能大于页。这个观点首先是错误的,对于 innodb,建立一张表,预分配 6 个数据页;插入一条数据后,占用三个数据页,一个数据页包含基本信息,一个数据页包含聚簇索引信息(没有显示指定会有生成隐式的),另外一个页包含的是插入的数据,数据行长度超过七千五比特还会有一个行迁移数据页( 7500 是大概值,具体忘了)
    2.关于页层次的问题。首先,MySQL 是个插拔式引擎的数据库,innodb 只是其中一种存储引擎。所以个人觉得,这里并没有层次高低的问题,只是两种不同层面的说法而已;但是 mysql 层面的页包含的东西会更大些而已
    cherryQWE
        2
    cherryQWE  
       2020-12-16 17:31:52 +08:00
    问:...一张表如果只存一行数据明显不可能大于页,那是不是可以理解在这种情况下表锁的粒度要小于页锁?
    答:不会啊,只有一条数据的话,也是存在一个 16k 页上,表是页的外层容器(找不到合适的词,就暂定容器吧),总之,页的大小是固定的,少于一个页了还是一个页,多了继续新增页。

    问:...其次,innodb 中的页相较于页锁中的页感觉抽象层次更低,也就是说完全是不同层次的概念了,毕竟 innodb 中的页是存数据的地方了...
    答:DB 内部也有一套存储结构啊,怎么会和 OS 混一起呢,两层东西呀。

    你要不看看源码得了,就不会这么纠结了。
    cherryQWE
        3
    cherryQWE  
       2020-12-16 17:34:42 +08:00
    一个 InnoDB 页中存储了一堆槽,槽记录的是每个数据块中最小行记录(按某种方式排序:主键或者索引键),但是每个槽对应一个数据块,这个数据块里面又有很多数据行....
    Cyshall
        4
    Cyshall  
    OP
       2020-12-16 17:55:32 +08:00
    @xsm1890 懂了懂了,非常感谢。
    louettagfh
        5
    louettagfh  
       2020-12-16 21:51:23 +08:00
    @xsm1890 你这是哪里看的 InnoDB 的 B+ tree 插入一个 record 只占一个 Page, 没有什么单独的索引, 索引即数据.
    xsm1890
        6
    xsm1890  
       2020-12-17 10:42:50 +08:00
    @louettagfh 没错,可以说索引既数。总结这句话的人的意思是 innodb 的数据文件索引和数据是在同一个文件中(既 table_name.ibd 文件),而不是像 myisam 一样有单独的索引数据文件( table_name.MYI ),更不是你理解的那样没有单独的索引。我所说的页包含聚簇索引及下一个页包含一条数据,是 table_name.ibd 文件的内部数据组织方式,木有任何问题。
    louettagfh
        7
    louettagfh  
       2020-12-17 10:48:11 +08:00
    @xsm1890 这是 B+ tree 的组织方式,和 .ibd 没有关系.
    xsm1890
        8
    xsm1890  
       2020-12-17 11:21:59 +08:00
    @louettagfh 那 B+ tree 总得存在磁盘上吧?
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     890 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 21ms UTC 21:17 PVG 05:17 LAX 14:17 JFK 17:17
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86