你的mysql到底能存多少数据呢?

这篇具有很好参考价值的文章主要介绍了你的mysql到底能存多少数据呢?。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

参考借鉴文章 我说MySQL每张表最好不超过2000万数据,面试官让我回去等通知?
这里自己在总结一下,原因是相关知识欠缺,看别人的文章研究很久才弄明白,所以这里记录一些心得。

作者:阿杆
链接:https://juejin.cn/post/7165689453124517896
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

抛砖

很多人说,MySQL每张表最好不要超过2000万条数据,否则就会导致性能下降。阿里的Java开发手册上也提出:单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。
但实际上,这个2000万或者500万都只是一个大概的数字,并不适用于所有场景,如果盲目的以为表数据只要不超过2000万条就没问题了,很可能会导致系统的性能大幅下降。
实际情况下,每张表由于自身的字段不同、字段所占用的空间不同等原因,它们在最佳性能下可以存放的数据量也就不同。

引玉

概念

简单讲一下:
你的mysql到底能存多少数据呢?

  1. 一张数据表一般对应一颗或多颗树的存储,树的数量与建索引的数量有关,每个索引都会有一颗单独的树。

  2. 聚簇索引和非聚簇索引:
    主键索引也是聚簇索引(非叶子节点):只存储主键和索引列等索引数据。
    非主键索引都是非聚簇索引(叶子节点):存储真正的所有字段信息。

  3. B+树的查询是从上往下一层层查询的,一般情况下我们认为B+树的高度保持在3层以内是比较好的,也就是上两层是索引,最后一层存数据,这样查表的时候只需要进行3次磁盘IO就可以了(实际上会少一次,因为根节点会常驻内存),且能够存放的数据量也比较可观。

    如果数据量过大,导致B+数变成4层了,则每次查询就需要进行4次磁盘IO了,从而使性能下降。所以我们才会去计算InnoDB的3层B+树最多可以存多少条数据。

  4. MySQL每个节点大小默认为16KB,也就是每个节点最多存16KB的数据,可以修改,最大64KB,最小4KB。

节点存储

在Innodb的B+树中,我们常说的节点被称之为 页(page),每个页当中存储了用户数据,所有的页合在一起组成了一颗B+树;

页 是InnoDB存储引擎管理数据库的最小磁盘单位,我们常说每个节点16KB,其实就是指每页的大小为16KB。
这16KB的空间,里面需要存储 页格式 信息和 行格式 信息,其中行格式信息当中又包含一些元数据和用户数据。所以我们在计算的时候,要把这些数据的都计算在内。
你的mysql到底能存多少数据呢?

下边具体介绍下啥是页格式和行格式;

注意:如果你不明白,那么就不要硬去理解,先去看后边的计算环节,结合计算再来一点点看这些介绍,因为后边的计算用到的数据都要出自这里的介绍。

页格式

每一页的基本格式,也就是每一页都会包含的一些信息,总结表格如下:
你的mysql到底能存多少数据呢?

另外,当新记录插入到 InnoDB 聚集索引中时,InnoDB 会尝试留出 1/16 的页面空闲以供将来插入和更新索引记录。如果按顺序(升序或降序)插入索引记录,则生成的页大约可用 15/16 的空间。如果以随机顺序插入记录,则页大约可用 1/2 到 15/16 的空间。

除了 User Records和Free Space 以外所占用的内存是 38+56+26+8=128字节,每一页留给用户数据的空间就还剩 16 × 15/16 × 1024−128=15232字节(保留了1/16)。
当然,这是最小值,因为我们没有考虑页目录。页目录留在后面根据再去考虑,这个得根据表字段来计算。

重点是页目录,下边计算会取一个平均值,根据图上说的是每个槽(不用管啥是槽)会放4~8条,取平均值就是6条,一个槽会占用2byte(取最大值吧)。

行格式

首先,我觉得有必要提一嘴,MySQL5.6的默认行格式为COMPACT(紧凑),5.7及以后的默认行格式为DYNAMIC(动态),不同的行格式存储的方式也是有区别的,还有其他的两种行格式,本文后续的内容主要是基于DYNAMIC(动态)进行讲解的。(了解即可)

特性对比(了解即可):

  • DYNAMIC(动态):
    当使用 DYNAMIC 创建表时,InnoDB 会将较长的可变长度列(比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型)的值剥离出来,存储到一个溢出页上,只在该列上保留一个 20 字节的指针指向溢出页。

    优点
    DYNAMIC 行格式避免了用大量数据填充 B+ 树节点从而导致长列的问题。
    DYNAMIC 行格式的想法是,如果长数据值的一部分存储在页外,则通常将整个值存储在页外是最有效的。
    使用 DYNAMIC 格式,较短的列会尽可能保留在 B+ 树节点中,从而最大限度地减少给定行所需的溢出页数。

  • COMPACT(紧凑):
    将前 768 个字节和 20 字节的指针存储在 B+ 树节点的记录中,其余部分存储在溢出页上。

    列是否存储在页外取决于页大小和行的总大小。当一行太长时,选择最长的列进行页外存储,直到聚集索引记录适合 B+ 树页(文档里没说具体是多少😅)。小于或等于 40 字节的 TEXT 和 BLOB 直接存储在行内,不会分页。

言归正传:每一行的基本格式,总结表格如下:
你的mysql到底能存多少数据呢?
重点是事务ID和指针字段、行记录头信息 ,计算的时候要用,因为固定的值也要算上。

字符编码不同情况下的存储(重要)

char 、varchar、text 等需要设置字符编码的类型,在计算所占用空间时,需要考虑不同编码所占用的空间。

  • varchar、text等类型会有长度字段列表来记录他们所占用的长度,但char是固定长度的类型,情况比较特殊,假设字段 name 的类型为 char(10) ,则有以下情况:
  • 对于长度固定的字符编码(比如ASCII码),字段 name 将以固定长度格式存储,ASCII码每个字符占一个字节,那 name 就是占用 10 个字节。
  • 对于长度不固定的字符编码(比如utf8mb4),至少将为 name 保留 10 个字节。如果可以,InnoDB会通过修剪尾部空格空间的方式来将其存到 10 个字节中。
    如果空格剪完了还存不下,则将尾随空格修剪为 列值字节长度的最小值(一般是 1 字节)。
    列的最大长度为: 字符编码的最大字符长度×N,比如 name 字段的编码为 utf8mb4,那就是 4×10。
  • 大于或等于 768 字节的 char 列会被看成是可变长度字段(就像varchar一样),可以跨页存储。例如,utf8mb4 字符集的最大字节长度为 4,则 char(255) 列将可能会超过 768 个字节,进行跨页存储。

总结一下:

字符编码不同,字段所占用的字节也会不同,固定字符编码(比如ASCII码)就是写多少就是多少,char(10),就占用10个字节,不固定的(比如utf8mb4)超过10个字节就用字符编码的最大字符长度(utf8mb4的这个值是4,结尾的mb4就代表4个字节,这个可以自己去查)x N,那么char(20)占用字节=4 x 20 =80,如果结果大于768,那么就会跨页存储(知道就行)。

计算

计算InnoDB的3层B+树最多可以存多少条数据
计算之前,先回顾一下前边的东西,页格式和行格式;
存储总量 = 可变数据 + 固定数据;
可变数据就是我们实际要存储的数据,固定数据就是内置好的数据,从上边的两个表格就能看到了。

通过页格式的介绍,我们知道,刨除固定数据量之后,我们得到的剩余存储空间是15232字节

那么,我们开始计算不固定的数据量,也就是我们要存储的实际信息,这个就只能举例说明了。

  • 简单一例:

先计算单个节点的:
假设我们的主键id为 bigint 型,也就是8个字节;
那索引页中每行数据占用的空间就等于 8 + 6(事物ID[上表有写]) + 5(行记录头) = 19 字节。
每页可以存 15232 ÷ 19 ≈ 801 条索引数据。
那算上页目录的话,按每个槽平均6条数据计算的话,至少有 801 ÷ 6 ≈ 134 个槽,需要占用 268 字节的空间。
所以最终的结果是(15232-268)÷ 19 ≈ 787条索引数据;
三层的数据量:
三层的叶子节点就是787²(反正就是这么算的,不用管,记住公式),也就是787x787= 619369 个叶子节点,每个节点可以存储787条数据,最终能存储 787 x 619369 = (自己算)条数据。
主键为 int 的表可以存放 993 ^ 2 = 986049 个叶子节点,下边会用。

  • 简单二例:

– 这是一张非常普通的课程安排表,除id外,仅包含了课程id和老师id两个字段
– 且这几个字段均为 int (4个字节)型(当然实际生产中不会这么设计表,这里只是举例)。
CREATE TABLE course_schedule (
id int NOT NULL,
teacher_id int NOT NULL,
course_id int NOT NULL,
PRIMARY KEY (id) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

每行数据所占用的空间就是 4 + 4 + 4 + 6 + 7 + 5 = 30 字节,每个叶子节点可以存放 15232÷30≈507条数据。
页目录占用空间:507 ÷ 685 x 2 = 170字节
算上页目录的槽位所占空间,每个叶子节点可以存放 (15232 - 170) ÷ 30502 条数据;
那么三层B+树可以存放的最大数据量就是 502×986049(主键是int)=494,996,将近5亿条数据!
  • 常规一例:

CREATE TABLE blog (
id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT ‘博客id’,
author_id bigint unsigned NOT NULL COMMENT ‘作者id’,
title varchar(50) CHARACTER SET utf8mb4 NOT NULL COMMENT ‘标题’,
description varchar(250) CHARACTER SET utf8mb4 NOT NULL COMMENT ‘描述’,
school_code bigint unsigned DEFAULT NULL COMMENT ‘院校代码’,
cover_image char(32) DEFAULT NULL COMMENT ‘封面图’,
create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘创建时间’,
release_time datetime DEFAULT NULL COMMENT ‘首次发表时间’,
modified_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘修改时间’,
status tinyint unsigned NOT NULL COMMENT ‘发表状态’,
is_delete tinyint unsigned NOT NULL DEFAULT 0,
PRIMARY KEY (id),
KEY author_id (author_id),
KEY school_code (school_code) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_general_mysql500_ci ROW_FORMAT=DYNAMIC;

1、行记录头信息:肯定得有,占用5字节。
2、可变长度字段列表:表中 title占用1字节,description占用2字节(虽然看着没超过255,但是用的是utf8mb4编码,所以实际是255 x 4,所以占用两个字节),共3字节。
3、null值列表:表中仅school_code、cover_image、release_time3个字段可为null,故仅占用1字节。
4、事务ID和指针字段:两个都得有,占用13字节。
5、字段内容信息:

  • id、author_id、school_code 均为bigint型,各占用8字节,共24字节。
  • create_time、release_time、modified_time 均为datetime类型,各占8字节,共24字节。
  • status、is_delete 为tinyint类型,各占用1字节,共2字节。
  • cover_image 为char(32),字符编码为表默认值utf8,由于该字段实际存的内容仅为英文字母(存url的),结合前面讲的字符编码不同情况下的存储 ,故仅占用32字节。
  • title、description 分别为varchar(50)、varchar(250),这两个应该都不会产生溢出页(不太确定),字符编码均为utf8mb4,实际生产中70%以上都是存的中文(3字节),25%为英文(1字节),还有5%为4字节的表情,则存满的情况下将占用:
    (50 + 250) × ( 0.7 × 3 + 0.25 × 1 + 0.05 × 4) = 765 字节。
统计上面的所有分析,共占用 869 字节,则每个叶子节点可以存放 15232 ÷869≈17条,算上页目录,仍然能放 17 条。
则三层B+树可以存放的最大数据量就是 17 × 619369(根据主键是bigint) = 10,529,27317,约一千万条数据

你的mysql到底能存多少数据呢?文章来源地址https://www.toymoban.com/news/detail-428600.html

到了这里,关于你的mysql到底能存多少数据呢?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 固态硬盘到底有多少种接口

    1.SATA 接口 SATA 接口是传统硬盘接口,老电脑升级固态硬盘一般 仅支持 SATA 接口和 mSATA 接口。 SATA 分 SATA1.0-3.0 , 目前市面上以 SATA3.0 居多,支持 SATA 的固态硬盘基本为 SATA3.0 接口。 SATA3.0 接口理论传输速度约为 6Gbs ,约是 600Mb/S 。   2.mSata 接口 mSATA 接口是 SATA 接口的迷你版

    2024年02月13日
    浏览(41)
  • 自动驾驶到底需要多少个传感器?

    由于传感器的成本从15美元到1美元不等,汽车制造商想知道车辆完全自动驾驶需要多少传感器。 这些传感器用于收集有关周围环境的数据,它们包括图像、激光雷达、雷达、超声波和热传感器。一种类型的传感器是不够的,因为每种传感器都有其局限性。这是传感器融合背后

    2024年03月08日
    浏览(45)
  • 关于WMT,市值空间到底有多少想象力?

    前不久,知名交易平台Kucoin、ZB以及抹茶等上线了WMT,众多一级市场他投资者获得了不菲的收益,据了解WMT的市场公募价格为0.2美金,而目前其二级市场价格为0.6929美金。在近期WMT作为Cardano生态的明星项目,在二级市场稳步上涨且走势喜人,备受投资者关注。那么WMT到底是一

    2024年02月11日
    浏览(40)
  • GPT到底要砸掉多少打工人的饭碗?

    今天我们继续来聊GPT 对工作的冲击问题 首先分享一个我最近在网上看到的 利用AI的暗黑方法 就是接下来 在很多对AI无感的那些公司里面 尤其是非科技公司 未来一两年 其实可能是打工人混日子的黄金时期 因为懂AI的下属 用1/10的时间 就可以把工作做得比原来更好 但是不懂

    2024年02月02日
    浏览(42)
  • 你的接口多少QPS?

    消息推送平台提会供接口给业务方进行调用,一般面试官看到了也会想问:「你这接口有多少的QPS?RT是多少?有压测过吗?业务增长,调用接口的量也在增长,这时候你会怎么办?」 对于这个问题,我提供下思路哈,你们可以根据自身技术栈的情况做一些简单修整。 聊些指

    2023年04月10日
    浏览(33)
  • 你搞清楚了吗?| GET请求方式的长度限制到底是多少?

    目录 📍 浏览器限制 📍 服务器限制 在大多数人的一贯认识中,一直认为get请求方式有2048B的长度限制,其实这种说法是有失偏颇的,甚至可以说是错误的。 这个问题一直以来似乎是被N多人误解,其实Http Get方法提交的数据大小长度并没有限制,而是IE浏览器本身对地址栏

    2024年02月05日
    浏览(42)
  • Mysql——》一棵B+树可以存放多少行数据

    推荐链接:     总结——》【Java】     总结——》【Mysql】     总结——》【Redis】     总结——》【Kafka】     总结——》【Spring】     总结——》【SpringBoot】     总结——》【MyBatis、MyBatis-Plus】 存储数据的位置 最小存储单元 备注 计算机磁盘 扇区 = 512字

    2023年04月21日
    浏览(35)
  • 大厂交易系统从0到1(01)-一笔交易到底涉及多少张表?

    退款逻辑,1个业务单号--关联多个支付单号--也关联多个退款单号?退款单号,关联优惠券返还的,也可在退款单列表关联吗?返还比例多少,是在优惠券系统设置? 整个交易、支付、清结算、账务体系杂糅,会产生很多单据、单号。再考虑正向、逆向,他们的关系更复杂。

    2024年01月18日
    浏览(37)
  • MySQL数据库精选(从入门使用到底层结构)

    DDL: 数据定义语言,用来定义数据库对象(数据库、表、字段) DML: 数据操作语言,用来对数据库表中的数据进行增删改 DQL: 数据查询语言,用来查询数据库中表的记录 DCL: 数据控制语言,用来创建数据库用户、控制数据库的控制权限 数据定义语言 数据库操作 查询所有数据

    2024年02月19日
    浏览(49)
  • 天天使用MySQL,你知道MySQL数据库能抗多少压力吗?附(真实案例)

            今天给大家分享一个知识点,是关于MySQL数据库架构演进的,因为很多兄弟天天基于mysql做系统开发,但是写的系统都是那种 低并发压力、小数据量 的,所以哪怕上线了也就是这么正常跑着而已,但是你知道你连接的这个MySQL数据库他到底能抗多大并发压力吗?如

    2024年02月09日
    浏览(37)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包