mysql 大字段_0809MySQL实战系列:大字段如何优化|数据存储结构

本文探讨了MySQL大字段导致的表体积过大问题及其对运维的影响。介绍了InnoDB存储结构,包括页类型、行存储结构,并讨论了不同字段类型如char和varchar的存储差异。建议在设计时考虑字段总和不超过8k以避免行溢出,并提出通过序列化、拆分大字段到子表或使用压缩来优化存储策略。
摘要由CSDN通过智能技术生成

背景

线上发现一张表,1亿的数据量,物理大小尽然惊人的大,1.2T

最终发现,原来有很多字段,10个varchar,1个text

这么大的表,会给运维带来很大的痛苦:DDL咋办?恢复咋办?备份咋办?

基本知识:InnoDB Storage Architecture for InnoDB On Disk Format

蓝图: database --> tablespaces --> pages --> rows --> columns

InnoDB 物理结构存储结构

3e6cb2c19de14c9c119d1cd3067e74e4.png

InnoDB 逻辑存储结构

b77dde92cf259e31bf6e3e51c6e796d8.png

InnoDB page 存储结构

页类型

数据页(B-tree Node)

undo页(undo Log Page)

系统页(System Page)

事务数据页(Transaction system Page)

插入缓冲位图页(Insert Buffer Page)

未压缩的二进制大对象页(Uncompressd BLOB Page)

压缩的二进制大对象页(compressd BLOB Page)

页大小

默认16k(若果没有特殊情况,下面介绍的都是默认16k大小为准)

一个页内必须存储2行记录,否则就不是B+tree,而是链表了

结构图

fad2910a65549d989288a159c3bcb780.png

InnoDB row 存储结构

rows 文件格式总体规划图

c8a2e2ca220d30a1c2c7c79de3399bf0.png

row-fomat为Compact的结构图

4b57182ba8705b57b9caf145c6488d48.png

row-fomat为Redundant的结构图

不常用

compress & dynamic 与 Compact 的区别之处

5f6408df8c981a76e06a260178097f58.png

字段之字符串类型

char(N) vs varchar(N)

不管是char,还是varchar,在compact row-format格式下,NULL都不占用任何存储空间

在多字节字符集的情况下,CHAR vs VARCHAR 的实际行存储基本没区别

CHAR不管是否是多字符集,对未能占满长度的字符还是会填充0x20

规范中:对char和varchar可以不做要求

varchar(N) : 255 vs 256

当实际长度大于255的时候,变长字段长度列表需要用两个字节存储,也就意味着每一行数据都会增加1个字节

实测下来存储空间增长并不算大,且性能影响也不大,所以,尽量在256之内吧

varchar(N) & char(N) 的最大限制

char的最大限制是: N<=255

varchar 的最大限制是: N<=65535

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值