关于MYSQL INNODB index page header学习和实验总结

关于INNODB  index header

所用到的工具是自己写的mysqlblock和bcview,
我放到了百度云盘
http://pan.baidu.com/s/1num76RJ
供大家下载和使用

普通表空间(及设置了innodb_file_per_table每个表都对应一个idb文件)从第4个块开始通常是innodb的数据页。
前38字节为FILE HEADER
从38字节到74字节为INDEX HEADER,如下:

number of directory slot            2bytes 槽的个数,
heap top position                   2bytes 块的最高数据记录的偏移地址
number of heap records/format flag  2bytes 行的记录数量但是第15位为行模式的标示如果15位为1,就是COMPACT模式
first garbage record offset         2bytes 第一行删除记录的偏移量
garbage space                       2bytes 删除的空间大小单位bytes
last insert position                2bytes 最后一个插入的位置偏移量
page direction                      2bytes 行的插入方向,取值为左,右或者无顺序 0x02 右 0x01 左  0x05 无序
number of inerts in page direction  2bytes 同一方向插入数据的行数,如果方向改变则重置
number of record                    2bytes 总的行数
maximum transaction id              8bytes 最大事物的ID
page level                          2bytes 页的级别,页节点为0,然后网上加1,如果3层,根节点为 2,分支节点为1,页节点为0
index ID                            8bytes 索引的ID这个在INNODB_SYS_INDEXES也是有的

接下来分析我设置了innodb_file_per_table
create table km1(id int ,name varchar(20));
insert into km1 values(1,'gaopeng');
insert into km1 values(2,'gaopeng');
insert into km1 values(3,'gaopeng'); 
insert into km1 values(4,'gaopeng'); 

分析文件:
[root@hadoop1 test]# mysqlblock km1.ibd -d|more
***************************************************
USEAGE: mysqlblock datafile -t/-d                  
This small tool used in study and test database,not
uesd on online database!                           
This tool is used to find how many blocks and types
in specified datafile,Exp:how many undo block in d 
ata file!                                          
QQ:2238980                                         
***************************************************
-t Only Total blocks types in ibdata!              
-d Blocks types detail  in ibdata!                 
***************************************************
FILE SIZE IS : 98304
current read blocks is : 0 --This Block is file space header blocks!
current read blocks is : 1 --This Block is insert buffer bitmap  blocks!
current read blocks is : 2 --This Block is inode blocks!
current read blocks is : 3 --This Block is data blocks( index pages)!
current read blocks is : 4 --This Block is new allocate blocks!
current read blocks is : 5 --This Block is new allocate blocks!
Total Block Status    :
Total  block                   :     6,Total size is: 0.093750 MB
Total undo block               :     0,Total size is: 0.000000 MB
Total inode block              :     1,Total size is: 0.015625 MB
Total insert buffer free blocks:     0,Total size is: 0.000000 MB
Total data(index pages) block  :     1,Total size is: 0.015625 MB
Total new allocate blocks      :     2,Total size is: 0.031250 MB
Total insert buf bitmap blocks :     1,Total size is: 0.015625 MB
Total system blocks            :     0,Total size is: 0.000000 MB
Total transaction system blocks:     0,Total size is: 0.000000 MB
Total file space header blocks :     1,Total size is: 0.015625 MB
Total extrenl disc blocks      :     0,Total size is: 0.000000 MB
Total LOB blocks               :     0,Total size is: 0.000000 MB
Total Unkown blocks            :     0,Total size is: 0.000000 MB

我这里数据很少,值有3条,所以一共就只有6个块,块3就是数据块(0 开始)使用

1、number of directory slot
bcview km1.ibd 16 38 2|more
current block:00000003--Offset:00038--cnt bytes:02--data is:0002
这里有一个槽的概念,他实际上是用于更快的定位数据,以后的文章会更加细节的研究学习

2、heap top position 
bcview km1.ibd 16 40 2|more
current block:00000003--Offset:00040--cnt bytes:02--data is:010c
表明记录的最高为出现在偏移量10c,及十六进制的268

3、number of heap records/format flag 

bcview km1.ibd 16 42 2|more
current block:00000003--Offset:00042--cnt bytes:02--data is:8006
这里8006十六进制,就说明是compact模式的行记录,如果使用Redundant我们看看
 create table km3 (id int,name varchar(20)) ROW_FORMAT = Redundant;
current block:00000003--Offset:00042--cnt bytes:02--data is:0002
可以看到这里第15为为0,说明是Redundant格式
而我们的行记录是6,明明只是插入了4条记录为什么是6呢,其实MYSQL的每个块里面有
2个虚拟列infimum 和supremum,他们都在固定的位置,而 infimum指向了第一条记录的
offset,而最后一条记录的offset表示为supremum的offset,这样形成了行记录的一个
单项链表。
4、first garbage record offset 
bcview km1.ibd 16 44 2|more
current block:00000003--Offset:00044--cnt bytes:02--data is:0000
为0,如果说明没有删除的记录,如果此时我们来delete 2条记录
delete from km1 where id in (1,3);
(由于bcview为基于文件的工具,修改的数据脏数据卸载buffer中,所以我重启了一次数据才能看到)
再次查看
current block:00000003--Offset:00044--cnt bytes:02--data is:00c9
看到这里为c9及offset 201

5、garbage space
bcview km1.ibd 16 46 2|more
current block:00000003--Offset:00046--cnt bytes:02--data is:004a
这里删除的字节为4a及74个字节,为什么我删除了2行数据却有这么多字节呢?
其实每行的数据除了数据本身还有很还有24个字节左右的开销,并且我们这里
没有主键的表MYSQL INNODB会自动生成一个6字节的48位的ROWID,那么加上就是
大约30个字节的开销,如果有建表的时候加上了主键ROWID 6字节开销就没了,同样
实验一下:
create table km4 (id int primary key,name varchar(1000));
insert into km4 values(1,'gaopeng');
insert into km4 values(2,'gaopeng');
insert into km4 values(3,'gaopeng'); 
insert into km4 values(4,'gaopeng'); 
delete from km4 where id in (1,3);
再次查看km4
 bcview km4.ibd 16 46 2|more
current block:00000003--Offset:00046--cnt bytes:02--data is:003
这里3e是十进制62,74-62=12 刚好6字节证明了我的说法。
还要注意一点:如果建表的时候没有加入主键,插入数据后加入,这每行6字节的开销也是有的,所以建表的时候尽量要加主键。
如果没有删除的行或者所有删除的空间从用了这个值减少为0.

6、last insert position 
bcview km1.ibd 16 48 2|more
current block:00000003--Offset:00048--cnt bytes:02--data is:0000

这个取值在没有删除重用空间的时候都0,但是随后的测试中这个值代表的
是最后一次插入的偏移量。如果使用的是删除的空间,那么这个值会出现
指向小于当前偏移量的情况,因为删除的数据的空间在当前行的物理偏移量
以前

7、page direction

bcview km1.ibd 16 50 2|more
current block:00000003--Offset:00050--cnt bytes:02--data is:0002

这里代表的插入的顺序为0x02 右

8、number of inerts in page direction
bcview km1.ibd 16 52 2|more
current block:00000003--Offset:00052--cnt bytes:02--data is:0003

这里代表以0x02 这个顺序插入数据的行数为4-1,因为我插入了4行它为3

9、number of record  
bcview km1.ibd 16 54 2|more
current block:00000003--Offset:00054--cnt bytes:02--data is:0002

可以看到这里的行数实际为2了因为我删除了2行,而
number of heap records/format flag
的记录还是8006,可以看到记录还是6,除掉infimum 和supremum还有4行。
那么我们可以得到一个结论
number of heap records 是本block中 delete的行数+未delete的行数+infimum 和supremum=6
而number of record     是本block中 未delete的行数

我们可以做下实验:
现在表中有2行,我们增加一行数据看看变化
mysql> insert into km1 values(5,'gaopeng');
number of record 
current block:00000003--Offset:00054--cnt bytes:02--data is:0003
number of heap records/format flag
current block:00000003--Offset:00042--cnt bytes:02--data is:8006
可以看到我们的空闲的空间重用了,因为number of heap records还是6,而number of record变成了3

那么还可以看看page direction和number of inerts in page direction
按照理论既然是重用了空间,那会插入的顺序是相反的,那么这两个值会有所变化
不出所料
page direction
current block:00000003--Offset:00050--cnt bytes:02--data is:0005
值为5
number of inerts in page direction
current block:00000003--Offset:00052--cnt bytes:02--data is:0000
变为了0,因为顺序改变了0X02改变为0X05那么这个值被重置了

同时我们这个时候来看
last insert position
bcview km1.ibd 16 48 2|more
current block:00000003--Offset:00048--cnt bytes:02--data is:00c9
以前这值是
current block:00000003--Offset:00048--cnt bytes:02--data is:0000
而这个值刚好也是 刚才 删除数据后first garbage record offset 的值
current block:00000003--Offset:00044--cnt bytes:02--data is:00c9
而此时值first garbage record offset
bcview km1.ibd 16 44 2|more
变为了
current block:00000003--Offset:00044--cnt bytes:02--data is:007f
这里7f变得更小,这个就是我们id=1的地址,而id=3的地址已经重用了

10、maximum transaction id 
bcview km1.ibd 16 56 8|more
current block:00000003--Offset:00056--cnt bytes:08--data is:0000000000000000

这个值应该代表是所有行中最高的事物ID,但是没有测试出来

11、page level 
 bcview km1.ibd 16 64 2|more
current block:00000003--Offset:00064--cnt bytes:02--data is:0000

代表是索引的层次,这里根节点是页节点是一个节点所以是0

12、index ID 

bcview km1.ibd 16 66 8|more
current block:00000003--Offset:00066--cnt bytes:08--data is:0000000000000255
这是索引的ID这个在INNODB_SYS_INDEXES也是有的。

学习了这些内容,我们有了一些对INDEX PAGE结构的了解。
总结一下:
1、heap top position 是块的高水位,就是索引页曾经达到的最高点。
2、last insert position 为最后一次索引页插入的行的偏移量,如果删除了数据会进行从用,那么这个值和heap top position并没有什么关系。
3、number of record 是块中未删除的数据量行数,每次删除和插入数据一定变化
4、number of heap records/format flag 记录的是 未删除行+删除行+infimum 和supremum的行数 ,未删除行可以重用,所以这个值可能在你插入数据后不会变化。
5、format flag是第15位的值1为compact格式,0为Redundant
6、如果不加入主键,那么会自动生成一个6字节48位的ROWID,它会加大你的存储空间,所以尽可能加入主键吧再建表的时候,建表插入数据后加入主键也不会改善
7、garbage space 就是删除数据DELETE后剩余的空间,随着不断的重用这个空间不断减少,如果没有delete后可以从用的空间为0
8、index ID 这是索引的ID这个在INNODB_SYS_INDEXES也是有的。

时间: 2024-09-15 19:17:59

关于MYSQL INNODB index page header学习和实验总结的相关文章

关于INNODB SYSTEM RECORD infimum和supremum的学习和实验研究

关于INNODB SYSTEM RECORD infimum和supremum的学习和实验研究 接上一篇  http://blog.itpub.net/7728585/viewspace-2063921/关于MYSQL INNODB index page header学习和实验总结  所用到的工具是自己写的mysqlblock和bcview,我放到了百度云盘http://pan.baidu.com/s/1num76RJ供大家下载和使用 接下来就是INDEX SYSTEM RECORDS,就是in

INNODB 页节点数据的存储方式、数据链、删除链的学习和实验总结

前文: 关于MYSQL INNODB index page header学习和实验总结  http://blog.itpub.net/7728585/viewspace-2063921/ 关于INNODB SYSTEM RECORD infimum和supremum的学习和实验研究  http://blog.itpub.net/7728585/viewspace-2065464/ 所用到的工具是自己写的mysqlblock和bcview,我放到了百度云盘http://pan.baidu.com/

MYSQL Space id in fsp header,but in the page header错误

今天启动MYSQL的时候发现如下问题: 2015-12-14 20:51:59 2098 [ERROR] InnoDB: Space id in fsp header 131225,but in the page header 65 2015-12-14 20:51:59 2098 [ERROR] InnoDB: inconsistent data in space header in tablespace ./test/oneblock.ibd (table test/oneblock) in

MySQL · 引擎特性 · InnoDB index lock前世今生

前言 InnoDB并发过程中使用两类锁进行同步. 1. 事务锁 维护在不同的Isolation level下数据库的Atomicity和Consistency两大基本特性. InnoDB定义了如下的lock mode: /* Basic lock modes */ enum lock_mode { LOCK_IS = 0, /* intention shared */ LOCK_IX, /* intention exclusive */ LOCK_S, /* shared */ LOCK_X,

ORACLE 索引和MYSQL INNODB 辅助索引对NULL的处理区别

ORACLE 索引和MYSQL INNODB 辅助索引对NULL的处理 我们清楚ORACLE中的b+索引是对键值的NULL进行存储的,以致于我们 IS NULL这种肯定是用不到索引的, 当然这提及的ORACLE表为堆表,索引为单列B+树索引,(有一种优化方式为建立组合索引如create index xx on tab(a,'1') 这样来保证索引记录NULL值 这样DUMP出来为 ..... row#11[7886] flag: ------, lock: 2, len=12 col 0; NU

巧用MySQL InnoDB引擎锁机制解决死锁问题

最近,在项目开发过程中,碰到了数据库死锁问题,在解决问题的过程中,笔者对MySQL InnoDB引擎锁机制的理解逐步加深. 案例如下: 在使用Show innodb status检查引擎状态时,发现了死锁问题: *** (1) TRANSACTION: TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starting index read mysql tables in use 1, loc

MySQL InnoDB 共享表空间和独立表空间

MySQL  InnoDB 共享表空间和独立表空间 官网:https://dev.mysql.com/doc/refman/5.6/en/innodb-multiple-tablespaces.html 前言:学习mysql的时候总是习惯性的和oracle数据库进行比较.在学习mysql InnoDB的存储结构的时候也免不了跟oracle进行比较.Oracle的数据存储有表空间.段.区.块.数据文件:mysql InnoDB的存储管理也类似,但是mysql增加了一个共享表空间和独立表空间的概念:

MySQL EXPLAIN命令详解学习(执行计划)

MySQL EXPLAIN命令详解学习(执行计划) MySQL EXPLAIN 命令详解 MySQL的EXPLAIN命令用于SQL语句的查询执行计划(QEP).这条命令的输出结果能够让我们了解MySQL 优化器是如何执行 SQL 语句的.这条命令并没有提供任何调整建议,但它能够提供重要的信息帮助你做出调优决策. 1 语法 MySQL 的EXPLAIN 语法可以运行在SELECT 语句或者特定表上.如果作用在表上,那么此命令等同于DESC 表命令.UPDATE 和DELETE 命令也需要进行性能改

Mysql 5.7 Gtid内部学习(八) Gtid带来的运维改变

依托前文的解析来讲5.7中 Gtid带来的运维改变,我想理解应该是更加深刻,这节主要讨论以下几个部分: 如何跳过一个事务 mysqldump导出行为的改变 5.7中搭建基于Gtid的主从 5.7中Gtid的主从的切换 5.7中在线改变Gtid模式 一.如何跳过一个事务 和传统基于位置的主从不同,如果从库报错我们需要获得从库执行的最后一个事务,方法有如下: show slave status \G 中的 Executed_Gtid_Set. show global variables like '