xml地图|网站地图|网站标签 [设为首页] [加入收藏]

能源节能

当前位置:手机网投123 > 能源节能 > InnoDB 逻辑存储结构

InnoDB 逻辑存储结构

来源:http://www.hshlvy.com 作者:手机网投123 时间:2019-09-24 13:51

近年来,在专门的职业中碰着了MySQL中如何存款和储蓄长度较长的字段类型难题,于是花了二11日多的流年抽空学习了弹指间,并且记录下来。

表空间

不无数据都放在表空间中。假设翻开了innodb_file_per_table采取,则InnoDB会为每张表开荒一个表空间。可是急需潜心的是表空间存放的只是多少、索引和插入缓冲bitmap页,别的数据举个例子undo音讯,插入缓冲索引页,系统业务音信,三遍写缓冲依旧会放在原本的分享表空间内。

若果rollback后,分享表空间不会自行减弱,不过会决断空间是还是不是需求(比如undo空间),若是无需的话,会将这么些空间标志为可用空间,供后一次undo使用。

Dynamic行格式

随后大家率先看一下行格式为Dynamic是怎么着存款和储蓄大额的:

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.7.14    |
+-----------+
1 row in set (0.00 sec)

mysql> show table status like 'row'G;
*************************** 1. row ***************************
           Name: row
         Engine: InnoDB
        Version: 10
     Row_format: Dynamic
           Rows: 0
 Avg_row_length: 0
    Data_length: 16384
Max_data_length: 0
   Index_length: 0
      Data_free: 0
 Auto_increment: NULL
    Create_time: 2017-01-03 22:45:16
    Update_time: NULL
     Check_time: NULL
      Collation: latin1_swedish_ci
       Checksum: NULL
 Create_options:
        Comment:
1 row in set (0.00 sec)

创造和compact格式同样的表:

CREATE TABLE `row` (
  `content` varchar(65532) NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1

insert into row(content) select repeat('a',65532);
Query OK, 1 row affected (0.03 sec)
Records: 1  Duplicates: 0  Warnings: 0

看下页布满:

[root@localhost mysql]# python py_innodb_page_info.py -v row.ibd 
page offset 00000000, page type <File Space Header>
page offset 00000001, page type <Insert Buffer Bitmap>
page offset 00000002, page type <File Segment inode>
page offset 00000003, page type <B-tree Node>, page level <0000>
page offset 00000004, page type <Uncompressed BLOB Page>
page offset 00000005, page type <Uncompressed BLOB Page>
page offset 00000006, page type <Uncompressed BLOB Page>
page offset 00000007, page type <Uncompressed BLOB Page>
page offset 00000008, page type <Uncompressed BLOB Page>
Total number of page: 9:
Insert Buffer Bitmap: 1
Uncompressed BLOB Page: 5
File Space Header: 1
B-tree Node: 1
File Segment inode: 1

第4页是数据页,第5-9页是二进制页。我们直接看磁盘中第4页的多少:

3073 0000c000  dc 2d b0 f5 00 00 00 03  ff ff ff ff ff ff ff ff  |.-..............|
3074 0000c010  00 00 00 00 00 a3 4b 59  45 bf 00 00 00 00 00 00  |......KYE.......|
3075 0000c020  00 00 00 00 00 36 00 02  00 a6 80 03 00 00 00 00  |.....6..........|
3076 0000c030  00 7f 00 05 00 00 00 01  00 00 00 00 00 00 00 00  |................|
3077 0000c040  00 00 00 00 00 00 00 00  00 64 00 00 00 36 00 00  |.........d...6..|
3078 0000c050  00 02 00 f2 00 00 00 36  00 00 00 02 00 32 01 00  |.......6.....2..|
3079 0000c060  02 00 1c 69 6e 66 69 6d  75 6d 00 02 00 0b 00 00  |...infimum......|
3080 0000c070  73 75 70 72 65 6d 75 6d  14 c0 00 00 10 ff f1 00  |supremum........|
3081 0000c080  00 00 00 02 00 00 00 00  00 07 07 a7 00 00 01 1b  |................|
3082 0000c090  01 10 00 00 00 36 00 00  00 04 00 00 00 26 00 00  |.....6.......&..|
3083 0000c0a0  00 00 00 00 ff fc 00 00  00 00 00 00 00 00 00 00  |................|
3084 0000c0b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
3085 0000c0c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
3086 0000c0d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
3087 0000c0e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
...
...
...

和Compact格式有着明显的分裂,当大数量在Page页寄存不下时,Dynamic行格式不会留768字节在Page页,並且将全部大数目都投身外界存款和储蓄页。具体的数据页和表面存款和储蓄页的连年关系同Compact格式同样。

咱俩再看看Dynamic格式的表面存款和储蓄页是否每贰个列独享外部存款和储蓄空间,依然同Compact格式实验进程同样:

CREATE TABLE `testblob` (
  `blob1` blob NOT NULL,
  `blob2` blob NOT NULL,
  `blob3` blob NOT NULL,
  `blob4` blob NOT NULL,
  `blob5` blob NOT NULL,
  `blob6` blob NOT NULL,
  `blob7` blob NOT NULL,
  `blob8` blob NOT NULL,
  `blob9` blob NOT NULL,
  `blob10` blob NOT NULL,
  `blob11` blob NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

mysql>   insert into testblob(blob1,blob2,blob3,blob4,blob5,blob6,blob7,blob8,blob9,blob10,blob11) select repeat('a',8000),repeat('b',8000),repeat('c',8000),repeat('d',8000),repeat('e',8000),repeat('f',8000),repeat('g',8000),repeat('h',8000),repeat('i',8000),repeat('j',8000),repeat('k',8000);
Query OK, 1 row affected (0.10 sec)
Records: 1  Duplicates: 0  Warnings: 0

看一下外界存储页数据:

 4599 00011f60  61 61 61 61 61 61 61 61  61 61 61 61 61 61 00 00  |aaaaaaaaaaaaaa..|
 4600 00011f70  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

好的,能够毫不向下看别的列的了,Dynamic的表面存款和储蓄页亦不是分享的。

然而MySQL为何要如此设计呢?或然是为着落到实处简单吗,沿着链表通过卓有成效数据大小就会读取blob的全部数码。假若多少个字段的blob混在协同,恐怕设计更目迷五色,要更新每一个字段的偏移量之类的,更新的话页数据管理也正如费心。小编的私有预计,呵呵。

小结下Dynamic格式存款和储蓄大数据的表征:

  • 当数码页放不下时,MySQL会将大数据总体坐落外界存款和储蓄页,数据页只留指向外界存款和储蓄页的指针。
  • 外界存款和储蓄页不分享,尽管多余二个字节也是独享16KB的页面。

由于有比较多的实验进程,所以呈现相比乱,提议看到那篇作品人自个儿实施一次,究竟自身出手会图谋越多的题目与细节,精晓的也比较深入,哈哈哈。

仿照效法资料:


区由三番五次的页组成,在别的情状下区的分寸都以1M。InnoDB存款和储蓄引擎一次从磁盘申请大约4-5个区。在暗中同意景况下,页的深浅为16KB,即贰个区中有大概63个延续的页。

正文同不常间宣布在

正文同时公布在

Compact行格式

作者们第一来看一下行格式为Compact是如何存款和储蓄大数据的:

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.1.73    |
+-----------+
1 row in set (0.01 sec)

mysql> show table status like 'row'G;
*************************** 1. row ***************************
           Name: row
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 1
 Avg_row_length: 81920
    Data_length: 81920
Max_data_length: 0
   Index_length: 0
      Data_free: 0
 Auto_increment: NULL
    Create_time: 2017-01-04 21:46:02
    Update_time: NULL
     Check_time: NULL
      Collation: latin1_swedish_ci
       Checksum: NULL
 Create_options: 
        Comment: 
1 row in set (0.00 sec)

小编们创设一张测量检验表,插入数据:

CREATE TABLE `row` (
  `content` varchar(65532) NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1

mysql> insert into row(content) select repeat('a',65532);
Query OK, 1 row affected (0.03 sec)
Records: 1  Duplicates: 0  Warnings: 0

大家利用py_innodb_page_info.py工具来查阅表中的页布满:

[root@localhost mysql]# python py_innodb_page_info.py -v com/row.ibd 
page offset 00000000, page type <File Space Header>
page offset 00000001, page type <Insert Buffer Bitmap>
page offset 00000002, page type <File Segment inode>
page offset 00000003, page type <B-tree Node>, page level <0000>
page offset 00000004, page type <Uncompressed BLOB Page>
page offset 00000005, page type <Uncompressed BLOB Page>
page offset 00000006, page type <Uncompressed BLOB Page>
page offset 00000007, page type <Uncompressed BLOB Page>
Total number of page: 8:
Insert Buffer Bitmap: 1
Uncompressed BLOB Page: 4
File Space Header: 1
B-tree Node: 1
File Segment inode: 1

能够见到,第4页的<B-tree Node>, page level <0000>格式为数据页,寄放着MySQL的行数据。<Uncompressed BLOB Page>能够精晓为MySQL贮存大数量的地点,近日叫作外界存款和储蓄页。Compact格式未有将大数目总体坐落数据页中,而是将一部分多少放在了表面存款和储蓄页中。那么,是整整数据在外界存款和储蓄页中,依然有些数量。即使是一部分数据,这一部分是稍稍吧?

大家接纳hexdump -Cv row.ibd翻开一下数据页<B-tree Node>, page level <0000>,约等于第4页:

3073 0000c000  8c 25 17 57 00 00 00 03  ff ff ff ff ff ff ff ff  |.%.W....????????|
3074 0000c010  00 00 00 00 00 07 3a b8  45 bf 00 00 00 00 00 00  |......:?E?......|
3075 0000c020  00 00 00 00 00 02 00 02  03 a6 80 03 00 00 00 00  |.........?......|
3076 0000c030  00 7f 00 05 00 00 00 01  00 00 00 00 00 00 00 00  |................|
3077 0000c040  00 00 00 00 00 00 00 00  00 13 00 00 00 02 00 00  |................|
3078 0000c050  00 02 00 f2 00 00 00 02  00 00 00 02 00 32 01 00  |...?.........2..|
3079 0000c060  02 00 1c 69 6e 66 69 6d  75 6d 00 02 00 0b 00 00  |...infimum......|
3080 0000c070  73 75 70 72 65 6d 75 6d  14 c3 00 00 10 ff f1 00  |supremum.?...??.|
3081 0000c080  00 00 00 04 03 00 00 00  00 13 12 80 00 00 00 2d  |...............-|
3082 0000c090  01 10 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |..aaaaaaaaaaaaaa|
3083 0000c0a0  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
3084 0000c0b0  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
3085 0000c0c0  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
....
....
3128 0000c370  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
3129 0000c380  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
3130 0000c390  61 61 00 00 00 02 00 00  00 04 00 00 00 26 00 00  |aa...........&..|
3131 0000c3a0  00 00 00 00 fc fc 00 00  00 00 00 00 00 00 00 00  |....??..........|
3132 0000c3b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
3133 0000c3c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
3134 0000c3d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
...
...
4093 0000ffc0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
4094 0000ffd0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
4095 0000ffe0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
4096 0000fff0  00 00 00 00 00 70 00 63  01 a1 6c 2b 00 07 3a b8  |.....p.c.?l+..:?|

我们能够看来,数据页中存放了一有的数据,算下来一共是768字节,然后剩余部分存款和储蓄在外界存款和储蓄页中。那么数据页与表面存款和储蓄页、外界存款和储蓄页与外表存款和储蓄页是哪些连接在共同的吗?

咱俩重点这一行:

3130 0000c390  61 61 00 00 00 02 00 00  00 04 00 00 00 26 00 00  |aa...........&..|
3131 0000c3a0  00 00 00 00 fc fc 00 00  00 00 00 00 00 00 00 00  |................|

这一行是前缀768字节的终极。注意最终的十多个字节:

  • 00 00 00 02:4字节,代表外界存款和储蓄页所在的space id
  • 00 00 00 04:4字节,代表第二个外表页的Page no
  • 00 00 00 26:4字节,值为38,指向blob页的header
  • 00 00 00 00 00 00 fc fc:8字节,代表该列存在外部存款和储蓄页的总市长度。此处的值为64764,加上前缀768正假诺65532。(注意一点,即使表示BLOB长度的是8字节,实际唯有4个字节约使用,所有对于BLOB字段,存款和储蓄数据的最大尺寸为4GB。)

评释下第4个外表存款和储蓄页的底部消息:

4097 00010000  cd c3 b6 8e 00 00 00 04  00 00 00 00 00 00 00 00  |?ö.............|
4098 00010010  00 00 00 00 00 06 b8 a2  00 0a 00 00 00 00 00 00  |......??........|
4099 00010020  00 00 00 00 00 02 00 00  3f ca 00 00 00 05 61 61  |........??....aa|
4100 00010030  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
...
...

前四十八个字节为File Header(关于InnoDB数据页的详实结构请参见《MySQL技艺内情InnoDB存款和储蓄引擎》4.4),这几个简单提一下:

  • cd c3 b6 8e:4字节,该页的checksum。
  • 00 00 00 04:4字节,页偏移,此页为表空间中的第5个页。
  • 00 00 00 00:4字节,当前页的上一个页。此页为<Uncompressed BLOB Page>,所以并没有上一页。
  • 00 00 00 00:4字节,当前页的下三个页。此页为<Uncompressed BLOB Page>,所以未有下一页。
  • 00 00 00 00 00 06 b8 a2:8字节,该页最终被涂改的日志体系地点LSN。
  • 00 0a:2字节,页类型,0x000A代表BLOB页。
  • 00 00 00 00 00 00 00 00:8字节,略过。
  • 00 00 00 02:页属于哪个表空间,此处指表空间的ID为2。

之后是4字节的00 00 3f ca,这里的值为16330,代表此BLOB页的管用数据的字节数。00 00 00 05表示下三个BLOB页的page number。

我们看最终三个<Uncompressed BLOB Page>,第8个页:

7169 0001c000  fa 78 9b 27 00 00 00 07  00 00 00 00 00 00 00 00  |?x.'............|
7170 0001c010  00 00 00 00 00 07 3a b8  00 0a 00 00 00 00 00 00  |......:?........|
7171 0001c020  00 00 00 00 00 02 00 00  3d 9e ff ff ff ff 61 61  |........=.????aa|
7172 0001c030  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
7173 0001c040  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
...
...

最终一页的卓有成效数据大小为0x00003d9e=15774,768+16330*3+15774 = 65532字节,符合伊始插入数据的高低。
出于这是终极三个<Uncompressed BLOB Page>,所以针对下一个<Uncompressed BLOB Page>的指针为ff ff ff ff。

经过大家得以很清晰的见到数据页与BLOB页的三番五次关系(援用天猫数据库月报上的一张图):
图片 1

大家来再看四个相比有趣的例证。:

CREATE TABLE `testblob` (
  `blob1` blob NOT NULL,
  `blob2` blob NOT NULL,
  `blob3` blob NOT NULL,
  `blob4` blob NOT NULL,
  `blob5` blob NOT NULL,
  `blob6` blob NOT NULL,
  `blob7` blob NOT NULL,
  `blob8` blob NOT NULL,
  `blob9` blob NOT NULL,
  `blob10` blob NOT NULL,
  `blob11` blob NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

mysql> insert into testblob select repeat('a',1000),repeat('b',1000),repeat('c',1000),repeat('d',1000),repeat('e',1000),repeat('f',1000),repeat('g',1000),repeat('h',1000),repeat('i',1000),repeat('j',1000),repeat('k',1000);
ERROR 1030 (HY000): Got error 139 from storage engine

大家树立一张新表,有10个blob字段。然后向各样字段插入1000字节的数额,MySQL会提示ERROR 1030 (HY000): Got error 139 from storage engine,什么看头呢?

InnoDB是以B+树来公司数据的,要是每一行数据都挤占一整个Page页,那么B+树将滑坡为单链表,所以InnoDB规定了二个Page必需包罗两行数据。约等于单排数据存款和储蓄在Page上的分寸大致为柒仟字节。
而地方的例证,一行数据有10个一千字节的多少,Page层料定放不下,所以在Page层留下768*11=8448字节,已经超(Jing Chao)过了7000字节,所以MySQL会唤起ERROR 1030 (HY000): Got error 139 from storage engine。大家很自在的概念三个字段,来存款和储蓄1一千个字节,不过却无法将他们分成13个字段来囤积,有一些意思!

那就是说怎么样化解地点的标题吧?

  • 将行格式转为接下去要说的Dynamic格式。此种格式只用20字节指向外界存款和储蓄空间。
  • 将多个blob字段转为多少个blob字段。多个字段能够用数组存款和储蓄,然后json_encode打包进blob。

大家向表中插入一条有效记录:

mysql>  insert into testblob(blob1,blob2,blob3,blob4,blob5,blob6,blob7,blob8,blob9) select repeat('a',8000),repeat('b',8000),repeat('c',8000),repeat('d',8000),repeat('e',8000),repeat('f',8000),repeat('g',8000),repeat('h',8000),repeat('i',8000);
Query OK, 1 row affected (0.12 sec)
Records: 1  Duplicates: 0  Warnings: 0

[root@localhost mysql]# python py_innodb_page_info.py -v com/testblob.ibd
page offset 00000000, page type <File Space Header>
page offset 00000001, page type <Insert Buffer Bitmap>
page offset 00000002, page type <File Segment inode>
page offset 00000003, page type <B-tree Node>, page level <0000>
page offset 00000004, page type <Uncompressed BLOB Page>
page offset 00000005, page type <Uncompressed BLOB Page>
page offset 00000006, page type <Uncompressed BLOB Page>
page offset 00000007, page type <Uncompressed BLOB Page>
page offset 00000008, page type <Uncompressed BLOB Page>
page offset 00000009, page type <Uncompressed BLOB Page>
page offset 0000000a, page type <Uncompressed BLOB Page>
page offset 0000000b, page type <Uncompressed BLOB Page>
page offset 0000000c, page type <Uncompressed BLOB Page>
Total number of page: 13:
Insert Buffer Bitmap: 1
Uncompressed BLOB Page: 9
File Space Header: 1
B-tree Node: 1
File Segment inode: 1

我们得以看来这一行数占有9个外表存款和储蓄页,而我们总结就插入了9列数据,是或不是当每一列的数据在page页放不下,都独立申请三个外表存款和储蓄页,而相互在此以前不分享外界存储页。大家看一下page页的协会就精通了:

 3130 0000c390  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61  |aaaaaaaaaaaaaaaa|
 3131 0000c3a0  61 61 61 61 00 00 00 05  00 00 00 04 00 00 00 26  |aaaa...........&|
...
...
 3180 0000c6b0  62 62 62 62 62 62 62 62  00 00 00 05 00 00 00 05  |bbbbbbbb........|
 3181 0000c6c0  00 00 00 26 00 00 00 00  00 00 1c 40 63 63 63 63  |...&.......@cccc|
...
...
 3229 0000c9c0  63 63 63 63 63 63 63 63  63 63 63 63 00 00 00 05  |cccccccccccc....|
 3230 0000c9d0  00 00 00 06 00 00 00 26  00 00 00 00 00 00 1c 40  |.......&.......@|
...
...

据悉前面包车型客车分析,大家往后能够见到,外界存款和储蓄页是不分享的,纵然一个列的数码多出一个字节,那一个字节也是独占贰个16KB空间的大大小小,那很浪费存款和储蓄空间。(当然,那对今世Computer也许不是主题素材,呵呵)。

说了那样多,统计下Compact格式存储大数指标欠缺:

  • 由于存在768字节的前缀在Page页,所以会设有能定义一个字段,存款和储蓄1一千字节,可是不可能定义12个字段,各个字段存款和储蓄1000字节的"bug"。
  • 表面存款和储蓄页不分享,即便多余二个字节也是独享16KB的页面。

InnoDB磁盘管理的细小单位。

  • B树节点= 贰个物理Page(16K)
  • 数据按16KB切片为Page 并编号
  • 编号可映射到大要文件偏移(16K * N)
  • B+树叶子节点前后变异双向链表

图片 2

  • 增加和删除改查之后
  • 立见成效Node组成双向链表
  • 中等存在空洞
  • 全表扫描时IO大概不一而再

至于页的详实结构,参谋:MySQL的InnoDB索引原理详解

MySQL差相当的少的逻辑存款和储蓄结构在这篇小说中有介绍,做为基本概念:InnoDB 逻辑存款和储蓄结构

表空间由各类段组成,比方数据段,索引段,回滚段等。

注:文中所指的大数目指的是长度较长的数据字段,包含varchar/varbinay/text/blob。

  • 率先推断表中是或不是有非空的举世无双索引,若是有,则该列为主键。
  • 假设不吻合上述条件,存款和储蓄引擎会自动创立三个6字节高低的指针。
行溢出

InnoDB存款和储蓄引擎能够将数据存款和储蓄到数据页之外。譬如大指标列类型常常会被贮存行溢出多少。

对此Compact和Redundant格式,存储情势如下:
图片 3

先在数额页面保存前768字节的多少,之后保存偏移量,指向行溢出页,也等于Uncompressed BLOB Page。

对于Compressed和Dynamic行格式,采取完全的行溢出办法:
图片 4

数量页只存放20字节的指针,实际数据贮存在off page中。

参照他事他说加以考察资料:《MySQL技能内部情状-InnoDB存款和储蓄引擎》

行记录格式

InnoDB 1.0.x之前:

  • Compact
  • Redundant 为了合营之前的版本

InnoDB 1.0.x之后

  • Compressed
  • Dynamic

翻开发银行格式的章程,注意row_format字段。

mysql> show table status like 'z'G;
*************************
           Name: z
         Engine: InnoDB
        Version: 10
     Row_format: Dynamic
           Rows: 2
 Avg_row_length: 8192
    Data_length: 16384
Max_data_length: 0
   Index_length: 0
      Data_free: 0
 Auto_increment: NULL
    Create_time: 2016-10-
    Update_time: 2016-10-
     Check_time: NULL
      Collation: latin1_s
       Checksum: NULL
 Create_options:
        Comment:
1 row in set (0.00 sec)

此地不详述各样行格式的格式了,有意思味的能够看参谋资料中的第4章。

InnoDB逻辑存储结构

  • 表空间 tablespace(ibd文件)
  • 段 segment(二个目录2个段)
  • Extent(1MB)
  • Page(16KB)
  • Row
  • Field

图片 5

数量是按行进行存放的。

要是创立表时从不出示的概念主键,mysql会按如下形式开创主键:

当表中有八个非空的当世无双索引,会挑选建表时首先个概念的非空独一索引。注意根据的是定义索引的次第,不是创立列的顺序。

本文由手机网投123发布于能源节能,转载请注明出处:InnoDB 逻辑存储结构

关键词: