【InnoDB 存储引擎】InnoDB 存储引擎的行格式,有 Compact、Redundant、Dynamic 等行格式还有它们配套实验(实验篇)

文章目录

  • 1 InnoDB 行记录格式(实验)
    • 1.1 Compact 行格式实验
      • 1.1.1 实验步骤
      • 1.1.2 分析捞出来的数据
      • 1.1.3 疑问
    • 1.2 Redundant 行格式实验
      • 1.2.1 实验步骤
      • 1.2.2 分析捞出来的数据
    • 1.3 CHAR 列类型的存储
      • 1.3.1 实验步骤
      • 1.3.2 分析捞出来的数据
  • 2 参考资料

1 InnoDB 行记录格式(实验)

前言:

1、本文是对 InnoDB 行格式的实验,请先通读 InnoDB 行格式的理论后再来实验。理论参考我的文章:《InnoDB 行记录格式》

2、实验环境是 mysql 的 5.7.41 ,建议读者也采用 5.7 版本,如果是 8.0 版本可能会有些不同之处

3、mysql 中一般一页是 16KB 大小,所以有如下的页地址列表

第几页页起始地址
100000000
200004000
300008000
40000c000
500010000
600014000

4、从 0000c000 页开始为数据页(当然也不一定但本实验是这样的)

5、Linux 平台提供了 hexdump 命令把二进制文件打印成标准的文本形式

hexdump -C -v t1.ibd  > t1.txt

如上图所示,显示的是每行的地址,所以如果某详细地址找不到那就取前缀地址在 txt 文件中搜索。当然刚开始非常建议用户直接通过特殊数据(如特殊的插入数据 fff )直接在 txt 文件中搜索

1.1 Compact 行格式实验

1.1.1 实验步骤

  1. 准备数据

    CREATE TABLE `t1` (
    

a varchar(10),
b varchar(10) DEFAULT NULL,
c char(10) DEFAULT NULL,
d varchar(10) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPACT;
– 2、插入一些特殊数据
INSERT INTO t1 VALUES (‘a’, ‘bb’, ‘bb’, ‘ccc’);
INSERT INTO t1 VALUES (‘d’, ‘ee’, ‘ee’, ‘fff’);
INSERT INTO t1 VALUES (‘g’, NULL, NULL, ‘hhh’);


2. 进入 mysql 存放数据的目录,找到 t1.ibd 文件```shell
# 找到表 t1 的存储文件
cd /var/lib/mysql/innodb_learn
# 把二进制文件 t1.ibd 文件输出为 t1.txt
hexdump -C -v t1.ibd  > t1.txt
  1. 从 t1.txt 文件把我们感兴趣的数据捞出来

    3073 0000c000  99 23 78 a5 00 00 00 03  ff ff ff ff ff ff ff ff  |.#x.............|
    3074 0000c010  00 00 00 00 22 dd a6 52  45 bf 00 00 00 00 00 00  |...."..RE.......|
    3075 0000c020  00 00 00 00 00 56 00 02  00 ef 80 05 00 00 00 00  |.....V..........|
    3076 0000c030  00 d8 00 02 00 02 00 03  00 00 00 00 00 00 00 00  |................|
    3077 0000c040  00 00 00 00 00 00 00 00  00 61 00 00 00 56 00 00  |.........a...V..|
    3078 0000c050  00 02 00 f2 00 00 00 56  00 00 00 02 00 32 01 00  |.......V.....2..|
    3079 0000c060  02 00 1e 69 6e 66 69 6d  75 6d 00 04 00 0b 00 00  |...infimum......|
    3080 0000c070  73 75 70 72 65 6d 75 6d  03 02 01 00 00 00 10 00  |supremum........|
    3081 0000c080  2c 00 00 00 00 05 0a 00  00 00 00 2b cf ab 00 00  |,..........+....|
    3082 0000c090  01 92 01 10 61 62 62 62  62 20 20 20 20 20 20 20  |....abbbb       |
    3083 0000c0a0  20 63 63 63 03 02 01 00  00 00 18 00 2b 00 00 00  | ccc........+...|
    3084 0000c0b0  00 05 0b 00 00 00 00 2b  d0 ac 00 00 01 91 01 10  |.......+........|
    3085 0000c0c0  64 65 65 65 65 20 20 20  20 20 20 20 20 66 66 66  |deeee        fff|
    3086 0000c0d0  03 01 06 00 00 20 ff 98  00 00 00 00 05 0c 00 00  |..... ..........|
    3087 0000c0e0  00 00 2b d5 af 00 00 01  9b 01 10 67 68 68 68 00  |..+........ghhh.|
    3088 0000c0f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    

1.1.2 分析捞出来的数据

我们从捞出来的数据中其实已经看到我们刚刚插入的数据了,一共插入了 3 条数据

在一行数据的格式中,最重要最重要的就是 Record Header 和 RowID 2 项了!

第一行:

按照前面理论介绍,从具体数据如第一条数据 abbbb 按字节反推的到第一行数据整理后的格式如下:

03 02 01 						/*变长字段长度列表(倒序的)*/
00 								/* NULL 标志位列表 */
00 00 10 00 2c 					/* record header */
00 00 00 00 05 0a 				/* RowID【我们没有指定主键,是由系统自动生成的】 */
00 00 00 00 2b cf 				/* TranactionID */
ab 00 00 01 92 01 10 			/* Roll Pointer */
61 								/* 第1列数据 */
62 62							/* 第2列数据 */
62 62 20 20 20 20 20 20 20 20	/* 第3列数据 */
63 63 63						/* 第4列数据 */

1、变长字段列表是[03, 02, 01],跟我们插入的数据[ccc, bb, a]的长度是符合的。备注:char 列类型没参与长度的计算

2、NULL 标志位列表为 00 ,表明没有表不超过 8 个字段,且没有字段是 NULL

3、record header 最后 2 个字节 2c 指明了下一条记录的相对本条记录的偏移量,那我们来计算下下一条记录 rowid 的位置

1、本条记录的地址是:找到 RowID 的地址为:0000c081

2、偏移量是 2c,相加得到地址为:0000c0ad

3、查看 0000c0ad 的位置的数据为:00 00 00 00 05 0b

4、验证完全正确

4、第一列的数据为十六进制的 61,查表对应我们插入的数据:a

5、第二列第三列第四列也完全对应我们插入的数据:bb、bb、ccc

第二行:

请读者按第一行数据同样方式自行分析

第三行:

第三行跟前面 2 行略有不同,因为包含了字段为 NULL 的数据,重点观察一下 NULL 标志位列表的变化

在第 2 行地址的基础上加上偏移量直接得到第 3 行的地址为:0000c0ad + 2b = 0000c0d8,则有下面的结果

03 01							/*变长字段长度列表(倒序的)*/
06								/* NULL 标志位列表 */
00 00 20 ff 98					/* record header */
00 00 00 00 05 0c				/*【 RowID 重点】*/
00 00 00 00 2b d5				/* TranactionID */
af 00 00 01 9b 01 10			/* Roll Pointer */
67 								/* 第1列数据 */
68 68 68						/* 第4列数据 */
后面就是未使用的了,都是 00 00

1、变长字段为[03,01],第三行只有 2 个变长字段了其他字段为 NULL,跟我们插入的数据[hhh,g]吻合

2、NULL 标志位列表为 06,转化为二进制为 00000110,从右边往左边数,第 2、3 位是1 表示该记录的第 2、3 个字段是 NULL

3、在最后的数据列部分只有 2 列数据,因为为字段为 NULL 前面已经找到了也就不必在这里了

1.1.3 疑问

问题 1:为什么偏移量要根据 RowID 来偏移

因为没有比 RowID 更加合适的了

1、向前推理可以知道 NULL 标志位列表的长度、变长字段长度列表(刚好也解释了为什么变长字段的长度要倒序

2、往后推理根据各项占用的字节数,也可以方便的知道 TranactionID、Roll Pointer、各列的数据

那还是谁的地址合适呢?(其实还真有,就是页的地址,Redundant 就是使用这个地址作为偏移的参考标准)

1.2 Redundant 行格式实验

1.2.1 实验步骤

  1. 准备数据

    数据是复制的实验 Compact 行记录格式时的数据

    -- 注意行格式已经改成了REDUNDANT
    create table t2ENGINE = Innodb DEFAULT CHARSET=latin1 ROW_FORMAT =REDUNDANT
    select * from t1;
    -- 数据还是原来的数据
    select * from t2;
    +------+------+------+------+
    | a    | b    | c    | d    |
    +------+------+------+------+
    | a    | bb   | bb   | ccc  |
    | d    | ee   | ee   | fff  |
    | g    | NULL | NULL | hhh  |
    +------+------+------+------+
    3 rows in set (0.00 sec)
    
  2. 通过 hexdump 工具转换表空间 t2.ibd 文件为 t2.txt 文件

    hexdump -C -v t2.ibd > t2.txt
    
    3073 0000c000  ec bd 4c 64 00 00 00 03  ff ff ff ff ff ff ff ff  |..Ld............|
    3074 0000c010  00 00 00 00 22 dd fb 99  45 bf 00 00 00 00 00 00  |...."...E.......|
    3075 0000c020  00 00 00 00 00 59 00 02  01 0b 00 05 00 00 00 00  |.....Y..........|
    3076 0000c030  00 ea 00 02 00 02 00 03  00 00 00 00 00 00 00 00  |................|
    3077 0000c040  00 00 00 00 00 00 00 00  00 64 00 00 00 59 00 00  |.........d...Y..|
    3078 0000c050  00 02 00 f2 00 00 00 59  00 00 00 02 00 32 08 01  |.......Y.....2..|
    3079 0000c060  00 00 03 00 8a 69 6e 66  69 6d 75 6d 00 09 04 00  |.....infimum....|
    3080 0000c070  08 03 00 00 73 75 70 72  65 6d 75 6d 00 23 20 16  |....supremum.# .|
    3081 0000c080  14 13 0c 06 00 00 10 0f  00 ba 00 00 00 00 05 13  |................|
    3082 0000c090  00 00 00 00 2b fc ac 00  00 01 91 01 10 61 62 62  |....+........abb|
    3083 0000c0a0  62 62 20 20 20 20 20 20  20 20 63 63 63 23 20 16  |bb        ccc# .|
    3084 0000c0b0  14 13 0c 06 00 00 18 0f  00 ea 00 00 00 00 05 14  |................|
    3085 0000c0c0  00 00 00 00 2b fc ac 00  00 01 91 01 1e 64 65 65  |....+........dee|
    3086 0000c0d0  65 65 20 20 20 20 20 20  20 20 66 66 66 21 9e 94  |ee        fff!..|
    3087 0000c0e0  14 13 0c 06 00 00 20 0f  00 74 00 00 00 00 05 15  |...... ..t......|
    3088 0000c0f0  00 00 00 00 2b fc ac 00  00 01 91 01 2c 67 00 00  |....+.......,g..|
    3089 0000c100  00 00 00 00 00 00 00 00  68 68 68 00 00 00 00 00  |........hhh.....|
    3090 0000c110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    

1.2.2 分析捞出来的数据

在理论部分已经明确了 Redundant 的格式为:字段长度偏移列表、记录头(6个字节)

第一行:

23 20 16 14 13 0c 06				/* 字段长度列表,为什么有7个啊,明明我们只有4个字段*/
00 00 10 0f  00 ba					/* record header 记录头。不同于Compact格式记录头占用5个字节,Redundant记录头占用6个字节*/
00 00 00 00 05 13					/* RowID */
00 00 00 00 2b fc					/* TranactionID */
ac 00  00 01 91 01 10				/* roll pointer */
61									/* 第1列数据,字符'a' */
62 62								/* 第2列数据,字符'bb' */
62 62 20 20 20 20 20 20  20 20		/* 第3列数据,字符'bb',其余用空白字符填充 */
63 63 63							/* 第3列数据,字符'ccc' */

第一行的字段长度偏移列表为[23 20 16 14 13 0c 06],调整顺序为[06 0c 13 14 16 20 23],表示的含义是第1个字段的长度是6,第2个字段的长度是6(06 + 06 = 0c),第3个字段的长度是7(0c + 07 = 13),第4个字段的长度是1(13 + 01 = 14),第5个字段的长度是2(14 + 02 = 16),第6个字段的长度是10(16 + 0a = 20),第7个字段的长度是3(20 + 03 = 23)。为什么会多出3个字段我们只定义了4个字段现有有7个,这3个字段是隐藏字段

第1个字段:即 rowid,确实是占用6个字节

第2个字段:即 TranactionID,确实是占用6个字节

第3个字段:即 roll pointer,确实是占用7个字节

第4个字段:即字符’a’,确实是占用1个字节

第5个字段:即字符’bb’,确实是占用2个字节

第6个字段:即字符’bb’,但是是 char(10) 类型,确实是占用10个字节

第7个字段:即字符’ccc’,确实是占用3个字节

第二行:

第二行的数据请读者按第一行同样的自行整理

第一行记录的 rowid 地址是:0xc08a,偏移量是:ba,算出来第二行的地址是:0xC144,但是不对,因为在 Redundant 格式下偏移量相对的是页地址(0xc000)的偏移量,所以第二行的实际地址是:0xc000 + ba = 0xc0ba。根据地址把数据捞出来如下:

23 20 16 14 13 0c 06				/* 字段长度列表,为什么有7个啊,明明我们只有4个字段*/
00 00 18 0f 00 ea					/* record header 记录头 */
00 00 00 00 05 14					/* RowID */
00 00 00 00 2b fc					/* TranactionID */
ac 00  00 01 91 01 1e				/* roll pointer */
64									/* 第1列数据,字符'd' */
65 65								/* 第2列数据,字符'ee' */
65 65 20 20 20 20 20 20 20 20		/* 第3列数据,字符'ee',其余用空白字符填充 */
66 66 66							/* 第3列数据,字符'fff' */

第三行:

重点看一下第三行,因为第三行包括了 NULL 字段,重点关注下字段长度列表中是如何体现出 NULL 含义的

直接计算第三行的 rowid 地址为:0xc0ea,再整理后如下:

21 9e 94 14 13 0c 06				/* 字段长度列表,为什么有7个啊,明明我们只有4个字段*/
00 00 20 0f 00 74					/* record header 记录头 */
00 00 00 00 05 15					/* RowID */
00 00 00 00 2b fc					/* TranactionID */
ac 00 00 01 91 01 2c				/* roll pointer */
67									/* 第1列数据,字符'g' */
00 00 00 00 00 00 00 00 00 00		/* 第3列数据,全部是00 */
68 68 68							/* 第3列数据,字符'hhh' */

长度列表为[21 9e 94 14 13 0c 06],倒序后为[06 0c 13 14 94 9e 21],表示的含义如下:

第1个字段:第1个字段的长度是6,即 rowid,确实是占用6个字节

第2个字段:第2个字段的长度是6(06 + 06 = 0c),即 TranactionID,确实是占用6个字节

第3个字段:第3个字段的长度是7(0c + 07 = 13),即 roll pointer,确实是占用7个字节

第4个字段:第4个字段的长度是1,即字符’g’,确实是占用1个字节

第5个字段:

第6个字段:

第7个字段:即字符’hhh’,确实是占用3个字节

第5个字段的长度是:94 - 14 = 80,但是 80 表示的是符号位根本表示不了长度,那太好了很适合 NULL 这个特殊的类型

第6个字段的长度是:9e - 94 = 0a,表示的长度是 10,任然占用空间

可以看到对于 varchar 类型的 NULL 值,Redundant 同样不占用空间,而 CHAR 类型的 NULL 值需要占用空间

1.3 CHAR 列类型的存储

实验目的:

1、验证CHR(N)中的N指的是字符的长度,而不是字节长度

2、验证在不同的字符集下,CHAR类型列内部存储的可能不是定长的数据

通过 CHAR(N) 理论部分的介绍我们可以知道,

1.3.1 实验步骤

  1. 准备数据

    CREATE TABLE t1 (a char(2)
    ) CHARSET=GBK engine=InnoDB;
    
  2. 插入数据(含多字节的)

    INSERT INTO t1 SELECT 'ab';
    INSERT INTO t1 SELECT '我们';
    INSERT INTO t1 SELECT 'a';
    
  3. 查看每行数据的字符个数和字节个数

    mysql> SELECT a,CHAR_LENGTH(a),LENGTH(a) from t1;
    +--------+----------------+-----------+
    | a      | CHAR_LENGTH(a) | LENGTH(a) |
    +--------+----------------+-----------+
    | ab     |              2 |         2 |
    | 我们   |              2 |         4 |
    | a      |              1 |         1 |
    +--------+----------------+-----------+
    3 rows in set (0.00 sec)
    

    通过不同的CHAR_LENGTH和LENGTH函数可以观察到:前两个记录’ab’和’我们’字符串的长度都是2。但是内部存储上’ab’占用2字节,而’我们’占用4字节。如果通过HEX函数查看内部十六进制的存储,可以看到

    mysql> SELECT a,HEX(a) from t1;
    +--------+----------+
    | a      | HEX(a)   |
    +--------+----------+
    | ab     | 6162     |
    | 我们   | CED2C3C7 |
    | a      | 61       |
    +--------+----------+
    3 rows in set (0.00 sec)
    

    可以看到对于字符串’ab’,其内部存储为0x6162。而字符串’我们’为0xCED2C3C7。因此对于多字节的字符编码,CHAR类型不再代表固定长度的字符串了

1.3.2 分析捞出来的数据

通过 hexdump 工具查看表空间 t1.ibd 文件

对于UTF-8下CHAR (10)类型的列,其最小可以存储10字节的字符,而最大可以存储30字节的字符。因此,对于多字节字符编码的CHAR数据类型的存储,InnoDB存储引擎在内部将其视为变长字符类型。这也就意味着在变长长度列表中会记录CHAR数据类型的长度,下面查看下表 t1 的表空间文件:

hexdump -C -v t1.ibd > t1.txt

3073 0000c000  41 57 55 5a 00 00 00 03  ff ff ff ff ff ff ff ff  |AWUZ............|
3074 0000c010  00 00 00 00 22 dd cc 90  45 bf 00 00 00 00 00 00  |...."...E.......|
3075 0000c020  00 00 00 00 00 57 00 02  00 ce 80 05 00 00 00 00  |.....W..........|
3076 0000c030  00 b9 00 02 00 02 00 03  00 00 00 00 00 00 00 00  |................|
3077 0000c040  00 00 00 00 00 00 00 00  00 62 00 00 00 57 00 00  |.........b...W..|
3078 0000c050  00 02 00 f2 00 00 00 57  00 00 00 02 00 32 01 00  |.......W.....2..|
3079 0000c060  02 00 1c 69 6e 66 69 6d  75 6d 00 04 00 0b 00 00  |...infimum......|
3080 0000c070  73 75 70 72 65 6d 75 6d  02 00 00 00 10 00 1c 00  |supremum........|
3081 0000c080  00 00 00 05 0d 00 00 00  00 2b e0 b7 00 00 01 9c  |.........+......|
3082 0000c090  01 10 61 62 04 00 00 00  18 00 1e 00 00 00 00 05  |..ab............|
3083 0000c0a0  0e 00 00 00 00 2b e1 b8  00 00 01 a5 01 10 ce d2  |.....+..........|
3084 0000c0b0  c3 c7 02 00 00 00 20 ff  b7 00 00 00 00 05 0f 00  |...... .........|
3085 0000c0c0  00 00 00 2b e6 bb 00 00  01 a8 01 10 61 20 00 00  |...+........a ..|
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  |................|
3088 0000c0f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

整理后可以得到如下结果:

第一行:

02								/* 变长字段长度2,将CHAR视作变长类型 */
00								/* null 标志位列表 */
00 00 10 00 1c					/* record header */
00 00 00 00 05 0d				/* rowid */
00 00 00 00 2b e0				/* TranactionID */
b7 00 00 01 9c 01 10			/* roll pointer */
61 62							/* 字符,'ab' */

第二行:

04								/* 变长字段长度4,将CHAR视作变长类 */
00								/* null 标志位列表 */
00 00 18 00 1e					/* record header */
00 00 00 00 05 0e				/* rowid */
00 00 00 00 2b e1				/* TranactionID */
b8 00 00 01 a5 01 10			/* roll pointer */
ce d2 c3 c7						/* 字符,'我们' */

第三行:

02								/* 变长字段长度2,将CHAR视作变长类 */
00								/* null 标志位列表 */
00 00 20 ff  b7					/* record header */
00 00 00 00 05 0f				/* rowid */
00 00 00 00 2b e6				/* TranactionID */
bb 00 00 01 a8 01 10			/* roll pointer */
61								/* 字符,'我们' */

本实验清楚地显示了 InnoDB 存储引擎内部对 CHAR 类型在多字节字符字符集的存储。CHAR类型被明确视为了变长字符类型,对于未能占满长度的字符还是填充0x20。InnoDB存储引擎内部对字符的存储和我们用HEX函数看到的也是一致的。因此可以认为在多字节字符集的情况下,CHAR和VARCHAR的实际行存储基本是没有区别的

2 参考资料

官网:https://dev.mysql.com/doc/refman/8.0/en/innodb-row-format.html

InnoDB 行记录格式(理论):我的另外文章:《15.10 InnoDB 行记录格式(理论,重要)》

书籍:《InnoDB 存储引擎》,该书电子版练习作者无套路免费下载


传送门: 保姆式Spring5源码解析

欢迎与作者一起交流技术和工作生活

联系作者

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/14765.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

pnpm装包报错Run “pnpm install“ to recreate the modules directory.

一、先看报错 执行 pnpm install 装包报错 报错信息 ERR_PNPM_PUBLIC_HOIST_PATTERN_DIFF  This modules directory was created using a different public-hoist-pattern value. Run "pnpm install" to recreate the modules directory.二、解决方法 在项目根目录中…

【Zabbix 监控设置】

目录 一、添加 zbx-agent01 客户端主机1、服务端和客户端都配置时间同步2、服务端和客户端都设置 hosts 解析3、设置 zabbix 的下载源,安装 zabbix-agent24、修改 agent2 配置文件5、启动 zabbix-agent26、在服务端验证 zabbix-agent2 的连通性1、常用的键值 7、在 …

基于云原生网关的全链路灰度实践

作者: 倪海峰(海迩) 前言 随着企业规模的不断扩大,传统单体应用已很难进一步支持业务的发展,业务的迭代速度已经难以满足业务的增长,此时企业会对应用系统做微服务化的改造,降低业务的耦合度&…

Opencv图片样本预处理

前因 最近想学学,OPENCV识别物体,但是处理图片正样本时过于繁琐, 遂自己开发了工具,来处理样本图片,基于QT,文末附下载链接 程序 功能 一共有两个功能,一个是处理负样本,一个处理…

Spring Boot源码解读与原理分析(一):项目启动流程(上)——@SpringBootApplication

文章目录 〇、准备工作一、SpringBootApplication.java源码解析1.源码2.自定义注解3.组合注解4.注解ComponentScan过滤器 5.注解SpringBootConfigurationConfiguration 6.注解EnableAutoConfiguration 本文章是Spring Boot源码解读与原理分析系列博客的第一篇,将会介…

【js小案例】视频倍数播放、计算机、待办事项管理

视频倍数播放示例图&#xff1a; 视频倍数播放代码&#xff1a; <!DOCTYPE html> <html> <head><meta charset"UTF-8"><title>控制视频播放速度</title> </head> <body><video id"myVideo" width&quo…

10.1UEC++/UObject/UClass/UFunction/UPropret

1. 1.new出的对象&#xff0c;不用自己管理内存释放&#xff1b; 2.比如两个类对象指针a,b同时指向一个苹果&#xff0c;若苹果消亡&#xff0c;会将a,b同时指向空。 3.保存时&#xff0c;将工程中的actor&#xff0c;属性等能够保存在本地就是uob在发挥作用。 4.不管在ue&…

机器学习25:《数据准备和特征工程-III》采样和分隔

目录 1.采样和分割数据 1.1 抽样简介 1.2 过滤 PII&#xff08;个人身份信息&#xff09; 2.数据不平衡 2.1 下采样和增加权重 3.数据分割示例 3.1 随机分割可能不是最好的方法 4.分割数据 5.随机化 5.1 实际考虑 5.2 散列的注意事项 6.参考文献 1.采样和分割数据-…

时间序列预测 | Matlab自回归差分移动平均模型ARIMA时间序列预测

文章目录 效果一览文章概述部分源码参考资料效果一览 文章概述 时间序列预测 | Matlab自回归差分移动平均模型ARIMA时间序列预测,单列数据输入模型 评价指标包括:MAE、RMSE和R2等,代码质量极高,方便学习和替换数据。要求2018版本及以上。 部分源码 %% 清空环境变量 warnin…

Linux开发工具之【vim】

Linux开发工具之【vim】 文章目录&#xff1a; Linux开发工具之【vim】1. Linux软件包管理器yum1.1 查看软件1.2. 下载软件1.3 卸载软件 2. vim编辑器的使用2.1 vim常用模式2.2 vim基本操作2.3 vim命令模式命令集2.3.1 移动光标2.3.2 删除文字2.3.3 复制文本内容2.3.4 替换文本…

UE特效案例 —— 魔法翅膀

一&#xff0c;环境配置 创建默认地形Landscape&#xff0c;如给地形上材质需确定比例&#xff1b;添加环境主光源DirectionalLight&#xff0c;设置相应的强度和颜色&#xff1b;PostProcessVolume设置曝光&#xff0c;设置Min/Max Brightness为1&#xff1b; 与关闭Game Sett…

【SpringBoot3】--01.快速入门、基本框架原理、常用注解、yaml配置文件、日志配置

文章目录 SpringBoot3核心特性1.简介1. 1前置知识1.2 环境要求1.3SpringBoot是什么 2.快速入门2.1开发流程2.1.1创建项目2.1.2导入场景2.1.3 主程序2.1.4 业务2.1.5 测试2.1.6 打包 2.2 特性小结2.2.1 简化整合2.2.2简化开发2.2.3 简化配置2.2.4 简化部署2.2.5 简化运维 2.3 Sp…