「数据密集型系统搭建」原理篇｜数据类型不怕精挑细选

news2025/11/4 22:50:54

  本篇围绕MySQL数据库的底层存储模型、列类型来聊聊数据库表设计及建模中要注意的事项，剖析最根源的底层物理存储文件，用最真实的数据剖析来证明和解答开发过程中的疑惑。

  在一些技术谈资、面试沟通过程中，MySQL特别是我们常用的Innodb存储引擎，是非常高频的话题点，而现实中不难发现，很多朋友都浅尝辄止，只能“照本宣科”被动背诵一些概念，遗憾的是这并不足以让我们“精通”。究其主要原因还是因为物理存储文件的结构过于复杂，它的“可观测性”并不友好，并且，对于一般的软件开发者而言，与数据库的交互窗口更多聚焦在数据库工具界面，鲜有机会接触到物理存储内部，浮于概念化。

  本篇的目的就是解开MySQL中Innodb的神秘面纱直击第一现场来感受真实的数据存储，分析建模设计过程中列类型的影响，帮助更好地做好“精挑细选”。

探查真实的物理存储

关于Innodb部分的学习推荐如下资料入手和探究：

MySQL官方文档

MySQL技术内幕-Innodb存储引擎

Innodb Ruby（Innodb存储文件解析工具）

innodb文件分析工具innodb_ruby使用操作

Innodb物理存储层层剥开

数据库文件存储位置

  MySQL把我们的数据存储在哪里了？可以在命令行或数据库交互界面输入show variables like 'datadir'得到答案，即数据库文件存储位置。

-- 如:
show variables like 'datadir'
variable_namevalue
datadir/usr/local/mysql/data/

  我们再来创建一个数据库，取名为test，如下：

create database test;

  创建库后，我们在/usr/local/mysql/data/路径下得到一个名为test的文件夹，即新数据库空间存储路径，会用来存储该数据库的所有信息。

  我们再来创建一张测试表,也取名为test，如下：

CREATE TABLE `test` (
  `col_1` bigint(20) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`col_1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

  创建表后，我们在/usr/local/mysql/data/test路径下得到
test.frm、test.ibd两个文件，frm格式文件是MySQL架构层对于表结构定义的文件，与具体的存储引擎无关，而ibd文件则是Innodb存储引擎独有的，表结构选择该引擎后会以该格式文件进行物理存储，下面我们针对ibd文件进行深入分析。

ibd文件层层分解

  对于一个ibd文件而言，也是有层次、有组织结构的。整体上它是一个独立的表空间，只为一张表而服务（一般会这样配置）。

  从整体到具体、从大到小层层分解的话，可以描述为表空间（tablespace）、段（segment）、区（extent）、页（page），会从抽象到具体，从逻辑到现实，接近我们事实数据的部分。

💁 通俗解释：

  一般而言，表空间（tablespace）、段（segment）、区（extent）是层次结构中组织数据的抽象概念，是为层级服务的，像是学校、年级、班级的概念。

  页（page）才是真实存储和控制业务数据的原子结构，像是老师、学生的个体，每一个个体的信息都存储为行数据（Row）。

概念解释作用
表空间（tablespace）ibd文件最顶层概念存储分层结构组织
段（segment）表空间（tablespace）的下一层
区（extent）的上一层		存储分层结构组织
区（extent）段（segment）的下一层
页（page）的上一层		存储分层结构组织
页（page）ibd最底层、最原子概念真实存储数据的组织结构

  对于数据库的使用者而言更关注行数据（Row），而对于数据库，特别是Innodb存储引擎本身除了存储需求支撑，还要考虑更多特性的能力支持，如事务、索引等，功能支持来源于数据存储的结构铺垫，下面我们借助Innodb Ruby工具来层层拆解和分析ibd存储文件看看真实结构的形态。

以区域（extent） 视角，查看test表空间区域快照

# 这是Innodb Ruby的使用命令，具体可以参考上面资料
# -s 指定系统表空间文件
# -T 指定用户表空间、业务表
# space-extents-illustrate 以表空间extent段视角生成快照信息

innodb_space -s ibdata1 -T test/test space-extents-illustrate

image.png

  可以看到，在extent视角下当前表空间中一共有6个Page，具体解读如下：

Page Type(页类型)Pages（页数量）Ratio（占比）备注
System350.00%系统页
Index 50116.67%索引页，也就是我们常说的聚簇索引的一部分，它是我们熟悉的B+Tree的叶子结点，数据都是以此索引进行聚合，由于此时是刚建表的阶段没有数据填入，目前这棵树仅有一个节点
Free space233.33%空闲空间，链表数据结构，当一条记录被删除后，该空间会被加入到空闲链表中

以页（page） 视角，查看test表空间的页类型信息

# 这是Innodb Ruby的使用命令，具体可以参考上面资料
# -s 指定系统表空间文件
# -T 指定用户表空间、业务表
# space-page-type-summary 以表空间页类型Page Type视角生成快照信息

innodb_space -s ibdata1 -T test/test space-page-type-summary

image.png

  可以看到，在Page视角下，当前表空间中也是6个Page，具体解读如下：

Page Type页类型枚举可参考Innodb页类型，系统表空间、用户表空间对于页类型的使用是不同的，当前都是围绕用户表空间进行演示和分析。

type(页类型)count（数量）percent（占比）description（描述）页索引备注
FSP_HDR116.67%即File Space Header，文件空间头Page-0extent视图下属于System一部分
IBUF_BITMAP116.67%即Insert Buffer位图Page-1extent视图下属于System一部分
INODE116.67%Segment节点Page-2extent视图下属于System一部分
INDEX116.67%索引节点，B+Tree结构Page-3extent视图下属于index一部分
ALLOCATED233.33%最新分配的页Page-4、Page-5extent视图下属于free space一部分

剖析Page页结构核心

  经过上述Extent、Page视角拆解，我们已经推进到Page层面，Page页类型根据不同功能提供了具体的内部结构进行支撑，这里我们着重分析和业务数据存储息息相关的Index Page页类型，即构建聚簇索引的Page内部结构。

查看Index Page的内部结构

更多可参考Innodb数据页结构

# 这是Innodb Ruby的使用命令，具体可以参考上面资料
# -s 指定系统表空间文件
# -T 指定用户表空间、业务表
# -p 指定页，后面3是页的索引序号，从0开始，这里指定3是因为Page索引3的位置是Index Page，也就是聚簇索引所在页，可结合上述表述分析得到
# page-illustrate 以表空间指定页Page视角生成快照信息

innodb_space -s ibdata1 -T test/test -p 3 page-illustrate

image.png

  解读如上Index Page内部结构如下：

Region Type（区域类型）Bytes（字节空间）备注
FIL Header38文件头
Index Header36索引头
File Segment Header20即FSEG Header，文件
Infimum13虚拟行记录，限定记录最小边界，比最小的任何主键值还小，是System Records的一部分
Supremum13虚拟行记录，限定记录最大边界，比最大的任何主键值还大，是System Records的一部分
Page Directory动态稀疏目录，记录数据的相对位置，一个槽（Slots）可能拥有多条记录，二叉查找的结果只是一个粗略的结果。
B+树索引并不能找到具体的一条记录，能找到的只是该记录所在的页。数据库把页载入到内存，然后通过Page Directory再进行二分查找。
FIL Trailer8检测页是否完整写入磁盘。前4字节代表页的checksum值，最后4字节和FIL Header中的FIL_PAGE_LSN相同。checksum的默认算法是CRC32。
Garbage0碎片空间
Free16252空闲空间

  至此，我们只得到了一个Index Page，你是否有疑问，行数据(Row) 存在哪个结构体里了呢？目前我们只是做了建表操作，还没有向表中插入任何数据，下面通过不断插入行数据来观察它的存储位置变化，以及不断“膨胀“后的Index Page填充满后是如何从一个单节点的Page演变为庞大的B+Tree的。

从孤独的Page成长为B+Tree

插入一条数据，观察Index Page的变化

# 插入一行数据 

insert into test(col_1) value (1);

image.png

  解读Index Page内部变化，如下：

Region Type（区域类型）Bytes（字节空间）变化
FIL Header3838 → 38
Index Header3636 → 36
File Segment Header2020 → 20
Infimum1313 → 13
Supremum1313 → 13
Page Directory44 → 4
Record Header 🆕50 ↗ 5（+5）
Record Data 🆕210 ↗ 21（+21）
FIL Trailer88 → 8
Garbage00 → 0
Free1625216252 ↘ 16226（-26）

  不难发现，Index Page结构中新增加了两列空间数据，随之Free空间由于被占用随之对应减少，空间字节数增减保持一致。

  • Record Header 行数据头
  • Record Data 行数据，业务数据即存储在此！

Record Header、Record Data一般也会统一叫做User Record，与System Record包含的Infimum、Supremum相对应，还有Garbage部分的碎片记录，叫做Garbage Record。

查看Index Page的存储信息

# 这是Innodb Ruby的使用命令，具体可以参考上面资料
# -s 指定系统表空间文件
# -T 指定用户表空间、业务表
# -p 指定页，后面3是页的索引序号，从0开始，这里指定3是因为Page索引3的位置是Index Page，也就是聚簇索引所在页，可结合上述表述分析得到
# page-dump 以表空间指定页Page，生成该页Page的全部存储结构信息

innodb_space -s ibdata1 -T test/test -p 3 page-dump

  dump出来的结构及数据内容较多，但是非常清晰和实用，可以耐心参考注释进行分析。

#<Innodb::Page::Index:0x00007fa8c71d86d0>:
fil header:
#<struct Innodb::Page::FilHeader
 checksum=3581687651,
 offset=3,
 prev=nil,
 next=nil,
 lsn=2641978,
 type=:INDEX,
 flush_lsn=0,
 space_id=33>

fil trailer:
#<struct Innodb::Page::FilTrailer checksum=3581687651, lsn_low32=2641978>

page header:

#<struct Innodb::Page::Index::PageHeader
 n_dir_slots=2,
 heap_top=146,
 n_heap_format=32771,
 n_heap=3,
 format=:compact,
 garbage_offset=0,
 garbage_size=0,
 last_insert_offset=125,
 direction=:no_direction,
 n_direction=0,
 n_recs=1,
 max_trx_id=0,
 level=0,
 index_id=51>

fseg header:

#<struct Innodb::Page::Index::FsegHeader

 leaf=
  <Innodb::Inode space=<Innodb::Space file="test/test.ibd", page_size=16384, pages=6>, fseg=2>,
  
 internal=
  <Innodb::Inode space=<Innodb::Space file="test/test.ibd", page_size=16384, pages=6>, fseg=1>>

sizes:
  header           120
  trailer            8
  directory          4
  free           16226
  used             158
  record            26
  per record     26.00

page directory:
[99, 112]

system records:

#<struct Innodb::Page::Index::SystemRecord
 offset=99,
 header=
  #<struct Innodb::Page::Index::RecordHeader
   length=5,
   next=125,
   type=:infimum,
   heap_number=0,
   n_owned=1,
   info_flags=0,
   offset_size=nil,
   n_fields=nil,
   nulls=nil,
   lengths=nil,
   externs=nil>,
 next=125,
 data="infimum\x00",
 length=8>

#<struct Innodb::Page::Index::SystemRecord
 offset=112,
 header=
  #<struct Innodb::Page::Index::RecordHeader
   length=5,
   next=112,
   type=:supremum,
   heap_number=1,
   n_owned=2,
   info_flags=0,
   offset_size=nil,
   n_fields=nil,
   nulls=nil,
   lengths=nil,
   externs=nil>,
 next=112,
 data="supremum",
 length=8>

garbage records:

records:
#<struct Innodb::Page::Index::UserRecord
 type=:clustered,
 format=:compact,
 offset=125,
 header=
  #<struct Innodb::Page::Index::RecordHeader
   length=5,
   next=112,
   type=:conventional,
   heap_number=2,
   n_owned=0,
   info_flags=0,
   offset_size=nil,
   n_fields=nil,
   nulls=[],
   lengths={},
   externs=[]>,
 next=112,

 key=
  [#<struct Innodb::Page::Index::FieldDescriptor
    name="col_1",
    type="BIGINT",
    value=1,
    extern=nil>],
 row=[],

 sys=
  [#<struct Innodb::Page::Index::FieldDescriptor
    name="DB_TRX_ID",
    type="TRX_ID",
    value=1471,
    extern=nil>,
   #<struct Innodb::Page::Index::FieldDescriptor
    name="DB_ROLL_PTR",
    type="ROLL_PTR",
    value=
     #<struct Innodb::DataType::RollPointerType::Pointer
      is_insert=true,
      rseg_id=41,
      undo_log=#<struct Innodb::Page::Address page=285, offset=272>>,
    extern=nil>],
 child_page_number=nil,
 transaction_id=1471,
 roll_pointer=
  #<struct Innodb::DataType::RollPointerType::Pointer
   is_insert=true,
   rseg_id=41,
   undo_log=#<struct Innodb::Page::Address page=285, offset=272>>,
 length=21>

插入更多数据，查看填满Index Page

  上面我们插入一条数据使用了26个字节，目前剩余空间为16226个字节，16226/26≈624，我们插入624行数据后再来观察下该表空间结构和存储变化。

  • 继续使用extent视角，查看表空间Page分布情况
# 这是Innodb Ruby的使用命令，具体可以参考上面资料
# -s 指定系统表空间文件
# -T 指定用户表空间、业务表
# space-extents-illustrate 以表空间extent段视角生成快照信息

innodb_space -s ibdata1 -T test/test space-extents-illustrate

image.png

  不难发现，free space page从2两个变成0了，index page从1个变成了3个，下面再来看下index page的具体情况。

  • 继续使用page 视角，查看test表空间的页类型信息
# 这是Innodb Ruby的使用命令，具体可以参考上面资料
# -s 指定系统表空间文件
# -T 指定用户表空间、业务表
# space-page-type-summary 以表空间页类型Page Type视角生成快照信息

innodb_space -s ibdata1 -T test/test space-page-type-summary

image.png

  此时，Index Page已经有3个Page，而Free space下ALLOCATED的2个Page已经不见，此时已经被Index Page使用，所以当前的Page索引位3、4、5全都是Index Page所属，我们来看下Index Page的索引摘要。

  • 查看Index Page索引摘要
# 这是Innodb Ruby的使用命令，具体可以参考上面资料
# -s 指定系统表空间文件
# -T 指定用户表空间、业务表
# -I 指定索引，即Index
# -l 指定层级，即level，这里使用0则是层级一，若只有一个Page节点，那么此时B+Tree只有一层，0即root根节点，如果B+Tree有多个level，那么会从0到更多上升，此时0是非叶子结点
innodb_space -s ibdata1 -T test/test -I PRIMARY -l 0 index-level-summary

image.png

innodb_space -s ibdata1 -T test/test -I PRIMARY -l 1 index-level-summary

image.png

  • 查看Page 3 \ 4 \ 5中的Record数据行记录

   🔸 查看Page-3的数据行记录

# 这是Innodb Ruby的使用命令，具体可以参考上面资料
# -s 指定系统表空间文件
# -T 指定用户表空间、业务表
# -I 指定索引，即Index
# -l 指定层级，即level，这里使用0则是层级一，若只有一个Page节点，那么此时B+Tree只有一层，0即root根节点，如果B+Tree有多个level，那么会从0到更多上升，此时0是非叶子结点
innodb_space -s ibdata1 -T test/test -p 3 page-records

Record 125: (col_1=1) → #4
Record 142: (col_1=288) → #5

   🔸 查看Page-4的数据行记录

innodb_space -s ibdata1 -T test/test -p 4 page-records

Record 125: (col_1=1) → ()
Record 151: (col_1=2) → ()
Record 177: (col_1=3) → ()
...
Record 7509: (col_1=285) → ()
Record 7535: (col_1=286) → ()
Record 7561: (col_1=287) → ()

   🔸 查看Page-5的数据行记录

innodb_space -s ibdata1 -T test/test -p 5 page-records

Record 125: (col_1=288) → ()
Record 151: (col_1=289) → ()
Record 177: (col_1=290) → ()
...
Record 8835: (col_1=623) → ()
Record 8861: (col_1=624) → ()
Record 8887: (col_1=625) → ()

  当前Index Page的3个Page以及它们各自的Record数据分布较为清晰，整理这颗B+Tree的结构关系图如下：

image.png

  至此，完成了Index Page从孤独的单个Page节点到一颗B+Tree的演变。我们借助Innodb Ruby工具对物理存储底层进行了较为细致的观察和整理，看到过程和变化，能够直接触摸到物理数据本身进行分析和学习，对于深入理解Innodb的存储乃至后续上层能力有非常大的帮助。

种类繁多的列类型

  综上，我们可看到Index Page中行数据（Record）决定了每一个Page的存储情况，影响每个Page的关联情况，从而影响到整颗B+Tree的结构，而每一个行数据（Record）的最原子组成就是列（Column），因此每一个列类型的存储需求从小到大影响着全局的存储形态和结构，下面我们来从列（Column）的存储需求入手，看看为什么要“精挑细选”。

参考 MySQL列类型存储需求

  在MySQL中列的类型可以分为三类，数值类型、文本类型、时间&日期类型，每一种具体类型对应着具体的存储需求，这些具体的存储大小整合在一起填满了Page页结构的存储分布。

数值类型

列类型存储需求
TINYINT1 Byte
SMALLINT2 Byte
MEDIUMINT3 Byte
INT, INTEGER4 Byte
BIGINT8 Byte
FLOAT(p)如果0 <= p <= 24为4个字节, 如果25 <= p <= 53为8个字节
FLOAT4 Byte
DOUBLE [PRECISION], item REAL8 Byte
DECIMAL(M,D), NUMERIC(M,D)变长；DECIMAL(和NUMERIC)的存储需求与具体版本有关：使用二进制格式将9个十进制(基于10)数压缩为4个字节来表示DECIMAL列值。每个值的整数和分数部分的存储分别确定。每个9位数的倍数需要4个字节，并且“剩余的”位需要4个字节的一部分。
BIT(M)大约(M+7)/8 Byte

文本类型

列类型存储需求
CHAR(M)M个字节，0 <= M <= 255
VARCHAR(M)L+1个字节，其中L <= M 且0 <= M <= 65535(参见下面的注释)
BINARY(M)M个字节，0 <= M <= 255
VARBINARY(M)L+1个字节，其中L <= M 且0 <= M <= 255
TINYBLOB, TINYTEXTL+1个字节，其中L < 28
BLOB, TEXTL+2个字节，其中L < 216
MEDIUMBLOB, MEDIUMTEXTL+3个字节，其中L < 224
LONGBLOB, LONGTEXTL+4个字节，其中L < 232
ENUM(‘value1’,‘value2’,…)1或2个字节，取决于枚举值的个数(最多65,535个值)
SET(‘value1’,‘value2’,…)1、2、3、4或者8个字节，取决于set成员的数目(最多64个成员)

VARCHAR、BLOB和TEXT类是变长类型，每个类型的存储需求取决于列值的实际长度(上表中的L表示)，而不是该类型的最大可能的大小。具体的L需要根据字符集进行判断。

日期&时间类型

列类型大小(bytes)范围格式小数点精度支持用途
YEAR11901/2155YYYY0年份值
DATE31000-01-01/9999-12-31YYYY-MM-DD0日期值
TIME3‘-838:59:59’/‘838:59:59’HH:MM:SS[0,6]时间值或持续时间
DATETIME81000-01-01 00:00:00/9999-12-31 23:59:59YYYY-MM-DD HH:MM:SS[0,6]混合日期和时间值
TIMESTAMP41970-01-01 00:00:00/2038 结束时间是第 2147483647 秒，北京时间 2038-1-19 11:14:07，格林尼治时间 2038年1月19日 凌晨 03:14:07YYYYMMDD HHMMSS[0,6]混合日期和时间值，时间戳

用现实数据解答困惑

  在设计数据建模时，根据业务需求选择合理的列类型不仅对Index Page单页友好，对于整体B+Tree的排列也会有帮助。

  一般而言，一个表的字段不建议超过20列，如果存储2000万左右的数据大概需要一颗2 ~ 3层的B+Tree就能够满足了。当然，现实业务需求总是“奇奇怪怪”，难免会有一些取舍或反范式，甚至存在暂时不合理的设计和实现把B+Tree搞的也非常奇特。

精致与粗糙的成本差距

  这里我们举例一个使用char设置定长和使用varchar可变长度的存储差异。

  • 首先，创建两张表，如下：
# 固定长度表
CREATE TABLE `test01` (
  `col_1` bigint(20) NOT NULL AUTO_INCREMENT,
  `col_2` char(50) NOT NULL, -- 这里的50是设置的最大长度，可设置范围是0 <= M <= 255
  PRIMARY KEY (`col_1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

# 可变长表
CREATE TABLE `test02` (
  `col_1` bigint(20) NOT NULL AUTO_INCREMENT,
  `col_2` varchar(50) NOT NULL,
  PRIMARY KEY (`col_1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
  • 分别插入2000条字节长度为10的col_2数据，如下：
DELIMITER;
CREATE PROCEDURE loop_insert()
BEGIN
    DECLARE idx int DEFAULT 1;
    WHILE idx <= 2000
        DO
            insert into test01(col_1, col_2) VALUES (null, '0123456789');
            insert into test02(col_1, col_2) VALUES (null, '0123456789');
            
            SET idx = idx + 1;
        END WHILE;
    COMMIT;
END;;
CALL loop_insert();
  • 查看两个表的数据存储情况，如下：

image.png

  可以看到，存储列字段长度为10个字节时，使用定长char(50)比使用可变长varchar(50)占用了更多的空间，多出了5个Page的空间使用。

  • 再来查看两个表的B+Tree层级情况，绘图整理如下：
表 - test01

image.png

表 - test02

image.png

  可以看到，定长char的Page平均只存储了大概不到200条Record，而可变长varchar的Page平均存储可达到400条，可变长varchar在Page的利用空间上有非常大的优势。

  • 查看Record在两个表中的偏移量情况，如下：
# test01表，第一个非叶子节点
innodb_space -s ibdata1 -T test/test01 -p 4 page-records

# 偏移量间隔为 <77> 字节
Record 126: (col_1=1) → (col_2="0123456789")
Record 203: (col_1=2) → (col_2="0123456789")
Record 280: (col_1=3) → (col_2="0123456789")
Record 357: (col_1=4) → (col_2="0123456789")
Record 434: (col_1=5) → (col_2="0123456789")
......

# test02表，第一个非叶子节点
innodb_space -s ibdata1 -T test/test02 -p 4 page-records

# 偏移量间隔为 <37> 字节
Record 126: (col_1=1) → (col_2="0123456789")
Record 163: (col_1=2) → (col_2="0123456789")
Record 200: (col_1=3) → (col_2="0123456789")
Record 237: (col_1=4) → (col_2="0123456789")
Record 274: (col_1=5) → (col_2="0123456789")
......

  可以看到，在当前用例中，存储同样数据大小时，定长char的每条记录行的偏移量是77字节，而可变长varchar的每条记录行的偏移量是37字节，量变引起质变，存储成本一目了然。

  除了存储成本的影响，还有查询效率的影响，尽管在Innodb的聚簇索引中是一颗多路树，会尽量保持足够“克制”的深度以便有更高性能支持，但叶子节点的增加会成为积攒层级增加的“诱因”，频繁的节点裂变也会造成节点平衡性变化和空间浪费。

推荐的列设计实践

  总结一些日常设计中列类型的选择和考量，如下：

列类型使用场景
char可控的固定值，性别、学段、难度等
varchar大部分不固定的文本，均可承载，关注长度即可
tinyint一般场景下的数量较少的枚举，较为经济实惠
int大部分常见的数值需求，范围一般可满足
bigint主键ID，理论上可以支持业务范围可用
decimal支持高精度的存储需求，不推荐使用float、double不同版本会有精度或转换问题
datetime推荐使用datetime记录时间，没有存储穷尽隐患

列设计的Q&A环节

时间列怎么选择？

  time、datetime、timestamp都支持小数点0~6的精度，year、date记录的是年份、年月日，因此不支持小数点时间精度。

  datetime、timestamp都可以用来记录年月日时分秒，也支持最大6位的小数点精度，但是timestamp占用4字节存储范围较小，从系统长久使用、健壮性以及后续维护成本来说不建议使用该类型来记录时间，datetime占用8字节存储范围较大，一般我们采用datetime来进行时间数据存储，能满足大部分业务场景对时间范围、精度的最大要求。

uuid或单号怎么选择？

  使用varchar，扩展性更好，支持字符和数字的混合，而且在可生成范围内没有未来长度瓶颈。

  不要被uuid输出的全数字形态而迷惑，可以了解下雪花算法的相关“套路”，它的本质是披着数字外壳的字符串，只要是字符串理论上就会超过最大数值类型的限制，因此从根儿上也不推荐使用迷惑的数值类型去存储字符串数据。

超大文本怎么存储怎么搞？

  一般可以使用text类型的进行存储超大文本数据，还有blob也可以支持二进制数据存储，比如图片、视频等信息，对于这两种列类型的存储需求和形式，Innodb有独特的支持，感兴趣可以参考以上过程自行拓展。

  需要注意的是，如果你在做云存储相关业务，相信你会有更好的数据库选择，而不是完全吊死在MySQL上进行穷尽式开发。

主键为什么要bigint unsigned auto_increment一套组合拳？

  • 『为什么是bigint』:

      bigint可以支持大部分业务范围内的主键范围需求，这个max是2^31-1，使用数值类型的存储空间更小，只需要8字节，其他字符类型空间随着位数增加占用更大，因此可以让叶子节点更紧凑，庞大数据量下Page节点更少，且数值天然支持自增。
  • 『unsigned的作用』:

      支持位更多，范围更大，容量更好。
设置范围
bigint(20)-2^63 (-9223372036854775808) ~ 2^63-1 (9223372036854775807)
bigint(20) unsigned0 ~ 18446744073709551615
  • 『保持自增的理由』:

      聚簇索引是一个B+Tree结构，叶子节点存储的全是主键值，具体的数据行存储在非叶子节点上。B+Tree核心特性是维护数据的有序性，自增插入有利于有序性的维护以及树自身平衡性，如果是随机数插入那么需要频繁的找到叶子节点上的插入位，可能频繁触犯叶子节点分裂或合并，效率非常低下。

为什么要限制表中的列数量？

  一般而言，我们会按照一个用户表一个表空间的形式维护，即一个table对应一个ibd文件，列越多意味着行数据越大，那么填充满一个Index Page的速度就越快，而Index Page的大小是固定的，想要存储更多的行数据就需要更多的Index Page空间来支持，随着Index Page数量的增加B+Tree的叶子节点也会进行分裂和维护对应边界保持性能。

  因此保持一定数量的列设置是友好的设计开始，我们常说的垂直切分表，除了从业务逻辑边界视角更为合理、清晰、解耦外，站在数据存储角度也会有很大提升，将繁多的列分散到多个表，对应多个表空间进行存储和维护，提升单个表空间的容积率和相对装载率，是维护性、操作性很高的设计实践。

🏄🏄🏄 以上便是本章的全部内容，如果觉得有所收获，欢迎 『点赞』、『收藏』、『关注』 一键三连支持喔~

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

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

JavaScript 作用域

JavaScript 作用域

文章目录JavaScript 作用域JavaScript 作用域JavaScript 局部作用域JavaScript 全局变量JavaScript 变量生命周期函数参数HTML 中的全局变量你知道吗?JavaScript 作用域 作用域可访问变量的集合。 JavaScript 作用域 在 JavaScript 中, 对象和函数同样也是变量。 在 JavaScr…
阅读更多...
ONES X 海银财富｜以敏捷流程管理，创新金融服务平台

ONES X 海银财富｜以敏捷流程管理，创新金融服务平台

近日&#xff0c;ONES 签约财富管理行业领跑者——海银财富&#xff0c;助力海银财富落地敏捷流程管理&#xff0c;打造从需求到交付的一体化平台&#xff0c;快速接受业务方的反馈&#xff0c;进行金融平台的迭代与优化。海银财富管理有限公司&#xff08;以下简称海银财富&am…
阅读更多...
拆机详解：1968年军用集成电路计算机 高级货赢在做工

拆机详解：1968年军用集成电路计算机 高级货赢在做工

halo大家好&#xff0c;这里是一天更两篇的Eric。 今天我在网上偶然看到一个拆军用计算机的&#xff0c;正好给你们分享一下。这可是1970年左右为了F4战斗机敌我识别系统打造的&#xff0c;虽说比之前说的Macintosh更加的挤也更大&#xff0c;不过做工够扎实。 上图&#xff…
阅读更多...
centos8安装RabbitMQ和erlang

centos8安装RabbitMQ和erlang

RabbitMQ 消息队列MQ RabbitMQ简称MQ是一套实现了高级消息队列协议的开源消息代理软件&#xff0c;简单来说就是一个消息中间件。是一种程序对程序的通信方法&#xff0c;其服务器也是以高性能、健壮以及可伸缩性出名的Erlang语言编写而成为什么使用MQ 在项目中&#xff0c;…
阅读更多...
QSyntaxHighlighter

QSyntaxHighlighter

一、描述 此类用于自定义语法高亮显示规则&#xff0c;是用于实现 QTextDocument 文本高亮显示的基类。 要自定义语法高亮显示&#xff0c;必须子类化 QSyntaxHighlighter 并重新实现 highlightBlock()。此函数将在合适的时机自动被调用。 highlightBlock() 函数将格式设置应…
阅读更多...
SOFA Weekly｜SOFANews、本周贡献 issue 精选

SOFA Weekly｜SOFANews、本周贡献 issue 精选

SOFA WEEKLY | 每周精选 筛选每周精华问答&#xff0c;同步开源进展欢迎留言互动&#xff5e;SOFAStack&#xff08;Scalable Open Financial Architecture Stack&#xff09;是蚂蚁集团自主研发的金融级云原生架构&#xff0c;包含了构建金融级云原生架构所需的各个组件&#…
阅读更多...
Rasa 3.x 学习系列-Rasa [3.4.0] - 2022-12-14新版本发布

Rasa 3.x 学习系列-Rasa [3.4.0] - 2022-12-14新版本发布

Rasa 3.x 学习系列-Rasa [3.4.0] - 2022-12-14新版本发布 任何人都可以学习Rasa之优秀Rasa学习资源推荐 欢迎同学们报名Gavin老师的Rasa系列课程，任何人都可以学习Rasa之优秀Rasa学习资源推荐： 1.NLP on Transformers高手之路137课 2 .Rasa 3.X 智能对话机器人案例开发硬核…
阅读更多...
五、k8s pod详解

五、k8s pod详解

文章目录1 pod介绍1.1 pod 定义2 pod配置2.1 基本配置2.2 镜像拉取2.3 启动命令2.4 环境变量2.5 端口设置2.6 资源配额3 Pod生命周期3.1 创建和终止3.2 初始化容器3.3 钩子函数3.4 容器探测3.5 重启策略4 Pod调度4.1 定向调度4.2 亲和性调度5 污点和容忍5.1 污点&#xff08;Ta…
阅读更多...
做短视频必须了解的6个问题，你知道几个答案呢？

做短视频必须了解的6个问题，你知道几个答案呢？

做短视频必须了解的6个问题&#xff0c;你知道几个答案呢&#xff1f; 最近好多朋友问了视频运营和创作的问题&#xff0c;把其中六个有代表性的问题和答案汇总在一起&#xff0c;公开给大家&#xff0c;希望对大家有所帮助。 1、账号被限流了怎么办&#xff1f; 随手拍十条…
阅读更多...
聚观早报 | 小米同时研发两款车；谷歌计划向印度最高法院上诉

聚观早报 | 小米同时研发两款车；谷歌计划向印度最高法院上诉

小米同时研发两款车&#xff1a;谷歌计划向印度最高法院上诉&#xff1b;苹果AR/MR头显部件延迟发货&#xff1b;2022年特斯拉在德汽车销量激增&#xff1b;纽约市教育部门禁止访问 ChatGPT 小米同时研发两款车小米第一款车为中型溜背式轿车&#xff08;内部代号 Modena 摩德纳…
阅读更多...
欧科云链任煜男：推动区块链创新，切忌陷入“过度金融化”的桎梏

欧科云链任煜男：推动区块链创新，切忌陷入“过度金融化”的桎梏

FTX破产轰动全球&#xff0c;揭示的是监管出现问题。FTX作为行业龙头&#xff0c;持有多国牌照却依然“暴雷”&#xff0c;未来到底应如何监管加密资产行业&#xff1f;针对这一问题&#xff0c;欧科云链控股(01499.HK)公司执行董事、董事局主席兼行政总裁任煜男近日在接受香港…
阅读更多...
【菜菜的CV进阶之路 - 深度学习环境搭建】windows+ubuntu20.04双系统安装

【菜菜的CV进阶之路 - 深度学习环境搭建】windows+ubuntu20.04双系统安装

新学期&#xff0c;配了台新电脑&#xff08;双路2080ti5800x64GB内存500GB固态2TB机械&#xff09;&#xff0c;师兄忙于毕设&#xff0c;没给装ubuntu&#xff0c;自己装一下咯~ 一、前期准备 1、空U盘一个 2、Ubuntu 20.04 LTS镜像 3、启动U盘制作软件&#xff08;我用的…
阅读更多...
STM51嵌入式开发入门软件安装-Keil、stc、驱动

STM51嵌入式开发入门软件安装-Keil、stc、驱动

STM51嵌入式开发入门软件安装-Keil、stc、驱动 STM51嵌入式开发入门软件安装-Keil、stc、驱动 1 Keil安装 1.1 百度进入官网 1.2 选择C51,点击后需要填的信息随便填 下载好的软件链接&#xff1a;https://pan.baidu.com/s/19wxkLD69QpmPNr27KYRAxw?pwdyihl 提取码&#xff1a…
阅读更多...
【web】微信小程序笔记小结（简介）

【web】微信小程序笔记小结（简介）

准备参加计算机设计大赛owo 疯狂学习微信小程序ing js也在努力兼顾kkk 写完想搞个目录结果老是跳转有问题orz&#xff0c;所以这一篇没有目录了qwq 来源&#xff1a;黑马程序员前端微信小程序开发教程 I. 小程序与普通网页的区别 ① 运行环境 网页 → 浏览器环境 小…
阅读更多...
自定义指令binding参数

自定义指令binding参数

除了核心功能默认内置的指令 (v-model 和 v-show)&#xff0c;Vue 也允许注册自定义指令。注意&#xff0c;在 Vue2.0 中&#xff0c;代码复用和抽象的主要形式是组件。然而&#xff0c;有的情况下&#xff0c;你仍然需要对普通 DOM 元素进行底层操作 如果想注册局部指令&#…
阅读更多...
自定义viewGroup

自定义viewGroup

案例分析&#xff1a;继承自extends LinearLayoutpublic class MainTabBarView extends LinearLayout实现3个方法public MainTabBarView(Context context) {this(context, null);}public MainTabBarView(Context context, Nullable AttributeSet attrs) {this(context, attrs, …
阅读更多...
Kettle--MySQL生产数据库千万、亿级数据量迁移方案及性能优化

Kettle--MySQL生产数据库千万、亿级数据量迁移方案及性能优化

一、Kettle环境搭建 一、Windows主要用于可视化创建数据迁移用到的ktr转换脚本、kjb作业脚本&#xff0c;以及脚本需要配置的DB2信息、读写性能优化信息等&#xff0c;也可直接在客户端完成不同数据库之间的数据迁移。 测试库表及数据 &#xff08;1&#xff09;创建测试库表…
阅读更多...
PVE安装win10并开启远程桌面

PVE安装win10并开启远程桌面

接上一篇一、win10安装镜像最新版下载下载地址&#xff1a;https://next.itellyou.cn/现在的win10最新版时22h2,文件名为zh-cn_windows_10_business_editions_version_22h2_updated_dec_2022_x64_dvd_cde06342.iso如果对更新有要求&#xff0c;建议每月跟踪下载一次二、上传win…
阅读更多...
IRCNN-FPOCS 代码解读（1）：整体框架

IRCNN-FPOCS 代码解读（1）：整体框架

0 前言 按照自己实现论文代码的思路&#xff0c;去研究作者的代码&#xff0c;找到自己的知识盲区和不足&#xff0c;提升编码技能。 本模块主要介绍代码实现思路。细节分析详见后续博客。 1、合成地震数据 利用波动方程&#xff1f;&#xff1f;&#xff1f;合成数据&…
阅读更多...
JavaScript的“神奇”之处

JavaScript的“神奇”之处

JavaScript 是一门很棒的语言。它的语法简单&#xff0c;生态系统也很庞大&#xff0c;最重要的是&#xff0c;它拥有最伟大的社区力量。我们知道&#xff0c;JavaScript 是一个非常有趣的语言&#xff0c;但同时也充满了各种奇怪的行为。让我们一起来看一下吧~ example 数组…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023