为什么说InnoDB必须要有主键并且推荐使用自增整型主键呢?

为什么InnoDB宜用自增主键 前言 领导:既然自增数字主键会导致主备同步时主键冲突,自增主键能不能砍掉? 答:自增主键主要是技术上提升效率,主键冲突可以考虑修改/插入时用唯一索引且不插入主键,而且, 公司规范:如果表记录超过1万行,建议用自增数字当主键,类型用BIGINT UNSIGNED。 InnoDB结构B+树 要了解InnoDB必须先了解B+树 主键B+树 B+树特点 有序 多叉树 叶子节点之间有引用,是一个链表 可以有效处理范围数据,如下图查询1-7行 定义Max. Degree = 4:节点达到4条记录就分裂,就是每 阅读详情

1.InnoDB存储引擎的数据结构必须需要一个主键才可以组织起来,如果用户使用InnoDB存储引擎建立表的时候,没有指定主键,则Mysql会自动的帮你找到一个合适的唯一索引作为主键,若找不到符合条件唯一索引条件的字段时,会生成类似于ROW_ID的虚拟列充当该InnoDB表的主键;

2.整型的存储比字段类型要小,而且应为是InnoDB存储引擎使用的是B+Tree数据结构,在进行查询数据是需要对每个元素进行比较,而整型的对比效率是高于其他数据结构的,字符串等。


使用自增主键作为InnoDB表的主键会存在一个问题?

Mysql中innodb_page_size = 16kb,选择BIGINT作为主键占用8b,地址也占8b 16kb/(8+8)b = 1000个元素,也就是1001阶的B+Tree树结构,那么每次新增新增一条记录都是在最右边的数据中插入新的数据,当插入1001个元素时,发生列变生成一个新的根节点,而此时的左子节点包含的元素个数是(1001-1)/2=500,此后不会再发生改变,因为每次插入的数据都是在整棵树的最右侧,以此类推会发现会有近乎一半的节点空间是浪费的。下图是以7阶的B+Tree示例:


B+树索引的分裂:

传统B+树页面分裂操做分析

  • 50%分裂策略的优点:
    • 分裂以后,两个页面的空间利用率是同样的;若是新的插入是随机在两个页面中挑选进行,那么下一次分裂的操做就会更晚触发;

  • 50%分裂策略的劣势:
    • 空间利用率不高:按照传统50%的页面分裂策略,索引页面的空间利用率在50%左右;
    • 分裂频率较大:针对如上所示的递增插入(递减插入),每新插入两条记录,就会致使最右的叶页面再次发生分裂

B+树分裂操做的优化

因为传统50%分裂的策略,有不足之处,所以,目前全部的关系型数据库,包括Oracle/InnoDB/PostgreSQL

新的分裂策略,在插入元素时且超出当前页的最大容量,不移动原有页面的任何记录,只是将新插入的记录写到新页面之中

好处:

  • 索引分裂的代价小:不须要移动记录;
  • 索引分裂的几率下降:若是接下来的插入,仍旧是递增插入,那么须要插入4条记录,才能再次引发页面的分裂。相对于50%分裂策略,分裂的几率下降了一半;
  • 索引页面的空间利用率提升:新的分裂策略,可以保证分裂前的页面,仍旧保持100%的利用率,提升了索引的空间利用率;

在InnoDB的实现中,为每一个索引页面维护了一个上次插入的位置,以及上次的插入是递增/递减的标识。根据这些信息,InnoDB可以判断出新插入到页面中的记录,是否仍旧满足递增/递减的约束,若满足约束,则采用优化后的分裂策略;若不满足约束,则退回到50%的分裂策略。

参考链接:https://www.cnblogs.com/mscm/p/13493129.html

为什么建议InnoDB表必须建立主键,并且推荐使用整型的自增主键 推荐一个国外的数据结构在线演示网站:https://www.cs.usfca.edu/~galles/visualization/Algorithms.html UUID:32个16进制数字,全球唯一,本地生成,性能高,没有网络耗时,但是非常长,占用大量的存储空间,并且作为主键建立索引和基于索引查询的时候会存在性能问题,一般这种方式不采用。 为什么InnoDB表必须建立主键 InnoDB中采用的是聚簇索引,表数据文件本身就是按照B+Tree组织的一个索引结构文件,主键索引默认就是B+Tree,由. 阅读详情

相关推荐

MySQL存储引擎MyISAM和InnoDB底层索引结构

目录 一 存储引擎作用于什么对象 二 MyISAM和InnoDB对索引和数据的存储在磁盘上是如何体现的 三 MyISAM主键索引与辅助索引的结构 1. 主键索引: 2. 辅助(非主键)索引: 四 InnoDB主键索引与辅助索引的结构 1. 主键索引: 2. 辅助(非主键)索引: 五 InnoDB索引结构需要注意的点 PS:为了更好地理解本文内容,我强烈建议先阅读完我的上一篇文章...

@子敬的博客 1万+

InnoDB为什么要设置主键?

在InnoDB存储引擎中,主键索引被称为聚集索引。因为在该存储引擎下,数据按照主键的逻辑顺序存储,该叶子存储不仅存储索引也存储数据,所以使用主键索引查询或排序操作会更加高效。总之,在InnoDB存储引擎中,主键不仅起到了标识记录的作用,还可以提供高效的索引结构,并加速了关联查询和其他表之间的数据评价。这些复合的主键字段可以被认为是组成一个复合索引,使它们能够在查询时进行更有效的利用。InnoDB存储引擎使用了B+树的数据结构来实现索引,这种结构使基于主键的关联操作变得非常快速和高效。

qq_56449176的博客 593

Ubuntu安装ToDesk远程控制软件

前几天有同学问我怎么在 Ubuntu 系统上安装 ToDesk 远程控制软件, 帮他安装完成后就 顺手整理了一下安装过程,所以就顺手有了这篇在 Ubuntu 系统上安装 todesk 的文章。

小白的博客 8660

【mysql】为什么建议InnoDB表必须建主键,并且推荐使用整型的自增主键?

因为聚簇索引,需要叶子节点存数据行,因此,如果存在主键,就默认把主键 参考: 《Mysql聚簇索引和非聚簇索引》 《聚簇索引和非聚簇索引:Mysql为什么建议使用自增id做主键》 误区

m0_45406092的博客 2816

第四章 自定义组件、动画

第三章 自定义组件、动画 (一)自定义View 1.1) onMeasure:对当前View的尺寸进行测量 protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) widthMeasureSpec和heightMeasureSpec包含测量模式和尺寸大小 int widthMode = MeasureSpec....

Stay Hungry Stay Foolish 求知若饥 虚心若愚 8132

告别“单打独斗”:Oh My Open Code 如何用多模型协作重塑 AI 编程范式

介绍"Oh My OpenCode"——一个能协调多个专业AI模型完成复杂开发任务的智能编程框架。您将看到它如何分配任务、发挥不同模型的独特优势,并通过并行处理和实时纠错等功能解决AI编程流程中的常见痛点。

老孙 | Ethan Sun 的博客:AI 智能体与 AI 原生软件的工程实践 4213

为什么InnoDB表必须有主键,并且推荐使用整型的自增主键?

innoDB索引文件和数据文件是在一起的 frm:表结构;ibd:索引文件和数据文件 问:为什么InnoDB表必须有主键。并且推荐使用整型的自增主键: 1、如果设置了主键,那么InnoDB会选择主键作为聚集索引、如果没有显式定义主键,则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引、如果也没有这样的唯一索引,则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(RO...

LZHHuo的博客 8549

关于Oxford Radar RobotCar Dataset的学习笔记

https://oxford-robotics-institute.github.io/radar-robotcar-dataset/documentation 简介 雷达是 Navtech CTS350-X 调频连续波 (FMCW) 扫描雷达,在所使用的配置中提供 4.38 cm 的距离分辨率和 0.9 度的旋转分辨率,范围高达 163 m,同时提供对天气条件的稳健性这可能会给其他传感器模式带来麻烦。在其他配置中,Navtech CTS350-X 可以提供超过 650 m 的范围和更高的旋转速度。然而,对

禾烁的博客 5297

为什么推荐InnoDB引擎使用自增主键?

原文地址:http://www.ywnds.com/?p=8735 在使用InnoDB存储引擎时,如果没有特别的需要,请永远使用一个与业务无关的自增字段作为主键,除非高并发写入操作可能需要衡量自增主键,后面会讲。 经常看到有帖子或博客讨论主键选择问题,有人建议使用业务无关的自增主键,有人觉得没有必要,完全可以使用如学号或身份证号这种唯一字段作为主键。不论支持哪种论点,大多数论据都是业务

奋斗、 9467

keil4.72添加GD32F10x芯片

1. 下载 GD32F10x_AddOn_V2.0.1.rar,解压缩。 2. 安装 运行GigaDevice.GD32F10x_AddOn.2.0.0.exe 安装位置 再新建工程,发现已经有GD32F10x 3. 增加的文件分析 运行GigaDevice.GD32F10x_AddOn.2.0.0.exe后,在keil文件夹种增加文件如下: ...

TrueLink的博客 2762

华为MetaERP的交易计税模块(即“税务引擎”)在设计上确实受到Oracle E-Business Tax(EBTax)等国际先进税务架构理念的影响,但结合了华为自身全球化运营、多准则合规、高并发处

华为MetaERP税务引擎在借鉴Oracle EBTax三层架构基础上,创新升级为五层智能税务架构,实现从"税码驱动"到"场景+规则+AI驱动"的转变。该模块采用云原生微服务架构,支持全球190+国家税务规则动态加载,具备实时计税、多准则并行处理、AI风险预警等核心能力,深度适配金税工程等国内合规要求。通过税务数字孪生、RPA机器人等创新,形成自主可控的智能税务中枢,为跨国企业提供全栈国产化税务解决方案,重新定义ERP税务管理范式。

金牌架构师 114

为什么建议主键整型自增?

我们从查找过程可以看到,整个过程关键点就是在这棵树上不停的比较id值是否等于、大于还是小于2,即数据的大小比较。数据比较是消耗CPU的,而不同的数据类型耗时不同,常见的整型要小于字符型。整型的1

ibigboy 809

ESM2蛋白预训练模型 蛋白质、氨基酸向量表示

参考: https://github.com/facebookresearch/esm https://huggingface.co/facebook/esm2_t33_650M_UR50D https://esmatlas.com/resources?action=fold tokenizer_对输入蛋白会头尾添加cls、eos特殊字符,占两个字符长度 参考:https://github.com/facebookresearch/esm 直接clone下来代码

weixin_42357472的博客 1万+

innoDB为什么必须要有主键,为什么推荐使用自增整型的主键?

如果主键为 UUID 整型容易比较大小进行排序,B+tree中的叶子节点和非叶子节点同层中都是从左到右有序递增的。mysql为了维护索引的有序性,使得新增的主键会在B+tree叶子节点中最后末尾添加,使得树分叉概率变小。 如有错误欢迎指正...

jj89929665的博客 684

河洛理数【陈抟】先天命卦大运

首先我们把前文提及的天干和地支进行上下划分,那么每一年的年份都是使用一天干和一地支进行组合,即如上的甲子、癸亥,那么下一年就是天干和地支都进行顺延一位进行组合,如甲子年下一年就是乙丑年,但是由于天干是十个、地支有十二个,所以要遍历一遍的话,就正好是 60 年。1924 年 ~ 1983 年(中元) 1984 年 ~ 2043 年(下元) 2044 年 ~ 2103 年(上元)2、找到卦中第一个(从下往上,也就是初爻、二到五爻、上爻)对应时辰的阴阳爻。5、也就是所属的元堂爻。

Daniel专栏 2073

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

为什么InnoDB表需要有主键

1.如果在innoDB 数据表的创建过程中,没有新建主键的话。自己会创建一个主键。 2. innoDB 的主键推荐为整型,自增id 3. 为啥不使用uuid 3.1 uuid 既不是整形,也不是自增 3.2 字符串比int 难比较 3.3 ssd 整型占据空间比较小 3.4 如果不是自增的话,需要下图平衡,对于insert不利 4.自增idd的讲述 哈希查询;不适用于范围索引。 B+ 数; 所有的叶子节点是排好序的。 叶子节点存储了相邻节点的位置,双向指针。 进行范围索引时:通过叶点之间的指针进行索引。

weixin_44824389的博客 1244

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

【大白话说Java面试题 第84题】【Mysql篇】第14题:为什么用 InnoDB 存储引擎的表建议用整型的自增主键?

摘要: InnoDB存储引擎推荐使用整型自增主键,核心原因基于性能与存储效率: 整型优势:CPU指令级高效比较(vs字符串逐字节对比);占用空间小(INT 4字节/BIGINT 8字节,远小于UUID的36字节),二级索引存储主键副本时空间放大效应显著。 自增优势:保证数据顺序插入B+树最右侧,减少页分裂(随机插入如UUID可能引发50%的页分裂,导致性能下降10-50倍),提升磁盘顺序I/O和缓存命中率。 分布式场景替代方案:Snowflake等8字节有序ID兼顾全局唯一与性能,避免UUID的存储和分裂问

Java后端 | AI智能体应用实战派 | 电脑技能行家 432

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

RU DOS版、EFI版32bit/64bit BIOS常用工具

DOS版、EFI版的RU工具,可用来查看IO、MEM、PCI、SMBIOS等资源。亲测在EFI SHELL下可用。

数据库用自增做主键好还是用自定义的主键好?

昨天在与别人的交流中我得知一个劝告:“设计数据库,你最好将自增id作为主键,而不是别的”。我想,为什么呢?为什么非得用一个与业务无关的自增ID作为主键呢?他还没有我的业务编号作为主键查找方便呢。于是,我带着疑虑,去求证这一劝告的真实性。 一、从数据在数据库的存储角度来看,自增id 是int 型,一般比自定义的属性(比如员工号,员工名字,或者用uuid等)作为主键,所占的磁盘空间都小很多。这样的话,在大型数据的查询、读写,前者的效率是比后者的效率高很多的。感兴趣的小伙伴可以用上百万的数据测试一下。 二、从数据

qq_42603181的博客 4299

Mysql原理刨析 :InnoDB存储引擎为什么需要设置主键?并且推荐使用整型的自增主键

1. 为什么要设置主键 ? 毫无疑问的是,当对Mysql中的表设置了InnoDB存储引擎的时候,那么就需要对一列数据建立索引,方便快速查找,如果不设置主键的,Mysql会在表中逐列对比寻找无重复项的列作为逐渐,如果没有查找到,那么Mysql会在表中添加默认列作为主键。如果不设置主键列,那么Mysql会消耗大量的资源去寻找索引列或者是创建新的索引列,如果设置了索引列那么将极大的降低Mysql的资源消耗。 2. 为什么要采用整型的数据 ? Mysql底层对数据查找的时候,会涉及到大量的对比操作,如果采用UUID

Mr_zhangbz的博客 792

为什么建议InnoDB表必须建主键,并且推荐使用整型自增主键?

本人自述 先说建索引的情况 如果你建了主键索引他会默认用主键索引来组织你整张表的数据。 如果你没有建的话又是另外一种情况 如果你没有建主键,他会帮你找一个主键,从表里面逐列去找一个列,这个列里面的数据是所有的数据都不重样。可以添加一个唯一索引。找到的话,他会用这一列的数据来组织你这个表的所有数据,用哪一个索引来建一个B+数的结构 来组织你表里的所有数据,如果你那个表里找不到这样的列,MySQL会自动给你找个隐藏列如12345,帮你自动维护这整张表的B+数的数据结构 推荐慕课学习资源,自己也在学习 [自己

小雨的博客 518

MYSQL-建innodb表必须要建主键WHY?

文章目录提问 :1.为什么建主键?a.b.2.为什么是整型?3.为什么自增?4.总结 提问 : 为什么mysql建innodb表必须要建主键,且DBA会推荐使用整型的自增主键? 1.为什么建主键? a. 因为ibd文件必须要用b+tree来组织,如果有主键,主键自带主键索引,那就可以用主键来组织整张表的数据。 b. 如果没有主键,数据该怎样存储呢? mysql会从第一列开始,选择一列所有元素都不相等的列,用这一列去组织一颗B+tree。 如果没有选到这样的列,mysql会帮你建一个隐藏列,它会自己维护一个唯

青苔小榭 1029

为什么MySQL的InnoDB引擎表强烈建议使用自增主键?

MySQL的InnoDB引擎作为最常用的存储引擎之一,官方文档和众多开发者都强烈建议使用自增主键(AUTO_INCREMENT)。这背后究竟隐藏着哪些关键原因?如果主键是自增的,新插入的数据会直接追加到索引末尾,避免频繁的页分裂操作。相比之下,UUID或字符串主键不仅占用更多存储空间,还会增加索引树的层级,导致查询时需要更多的磁盘I/O。总结来看,自增主键在InnoDB引擎中并非偶然选择,而是从性能、存储、并发到运维的全方位优化结果。例如,电商系统的订单表若采用自增ID,能有效避免高并发下的性能瓶颈。

cbmzzt_024的博客 164

【mysql】MyISAM和InnoDB索引结构分析

MyISAM和InnoDB索引结构分析 一、存储引擎作用于什么对象 存储引擎是作用在表上的,而不是数据库。 二 MyISAM和InnoDB对索引和数据的存储在磁盘上是如何体现的 先来看下面创建的两张表信息,role表使用的存储引擎是MyISAM,而user使用的是InnoDB: 再来看下两张表在磁盘中的索引文件和数据文件: 1. role表有三个文件,对应如下: role.f...

远方不远 1568

面试官:为什么不推荐使用 uuid 作为 mysql 主键?

主键是数据库表中的一个字段(或字段的组合),它具有唯一性、不为空性、数据完整性、关系参照、索引等特点和作用。其中主键的每个值必须唯一,用以区分表中的每条记录,也就是说一个表中不可能同时存在相同主键值的记录。索引数据库系统通常会为主键自动创建索引,从而提高基于主键的查询和访问数据的效率。在日常使用中,查询占据的比例往往是最大的,然而随着数据量的增大,在不使用索引作为辅助的时候,查询效率会越来越低。所以我们在使用MySQL的时候,往往都会建立索引,帮助优化查询效率。

码农小郑有话说的博客 1570

自增主键的前世今生

以MySQL(Innodb存储)为例介绍自增主键,介入场景分析主键的目的,从面试题下手,深入理解主键机制

RokoのBasilisk‘s Blog 354
上一篇: MyISAM引擎和InnoDB引擎的区别
下一篇: Mysql联合索引的数据结构(B+Tree)
悟道|养家
博客等级 码龄8年 33粉丝 66原创
评论 7
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值