为什么说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

基于python获取网易云热门歌单及封面

先看一下图片背后的代码 非常好,里面歌单名字,id,以及封面图片都有了.在复制url的时候注意把/#删掉,要不然爬不了. import requests from lxml import etree url='https://music.163.com/discover/playlist' head={ 'user-agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Ch

ziyuan12345678的博客 536

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

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

m0_45406092的博客 2816

攻防世界 misc题GFSJ1129-【您看我还有机会吗?】

我们发现了隐藏内容,一开始我以为那个英文就是flag,提交后发现不对,然后我想只有一张图片然后图片上的隐写内容又不是flag,那必定还有什么文件被隐藏了,于是我们打开VMware并启动Ubuntu,使用binwalk分析一下有没有隐藏文件,我们要在Terminal中分析,如下。我们发现里面有一个flag.txt文件,我们尝试提取里面内容,但发现又要密码,我们想起了之前图片上的隐藏内容,我们将那段英文输入(包括空格和符号,在VMware中输入密码不会有显示,你看到的就像没输入一样),然后我们看到如下。

大数据专业,关注 AI 安全与数学建模。记录 Web 安全、对抗攻击、隐私保护等安全实践,以及从经典模型到智能方法的建模思考。用数学思维理解 AI,用 AI 方法反哺安全与建模。 1095

LLVM实战:如何用Clang+LLVM打造你的第一个C++编译器(附完整配置步骤)

本文详细介绍了如何使用Clang+LLVM构建C++编译器的完整配置步骤,从环境准备到编译流程剖析,再到调试与优化技巧。通过实战指南,帮助开发者深入理解LLVM编译器框架的工作原理,并掌握交叉编译与性能分析等高级功能。

sprite的博客 748

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

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

LZHHuo的博客 8548

ERROR 1045 (28000): Access denied for user ‘root‘@‘localhost‘ (using password: NO)解决办法

问题:ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: NO) 很久没用这台电脑的mysql了,今天需要连接数据库,启动数据库报错: ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: NO) 解决方法: 查阅资料后知道了,应该使用已知的用户名和密码登陆 mysql -u root -p 然而密

一个超会写Bug的程序猿的博客 43万+

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

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

奋斗、 9467

ComfyUI-controlnet控制出图

提供加载预处理器节点。

Bu2n的博客 5494

VS2019 从零构建 OSG+OSGEarth+OSGQt 开发环境实战指南

本文提供了一份详细的实战指南,指导开发者如何在Windows系统下使用VS2019从零开始编译和配置OSG、OSGEarth与OSGQt开发环境。文章涵盖了从环境准备、源码获取、CMake配置、Visual Studio编译到最终测试的完整流程,并分享了关键的避坑技巧,旨在帮助三维GIS与可视化开发者高效搭建稳定、可控的专业开发平台。

weixin_28826961的博客 367

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

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

ibigboy 809

微信对话开放平台智能对话模块的几个亮点

微信AI首席科学家牛成公布了最新开放方案,并重磅宣布全面开放各层次 NLP 能力。具体说来,微信 AI 迈出了“三大步”: 以硬件合作为核心的智言小微硬件开放平台 2.0 正式亮相; 公开以对话开放能力为核心的微信对话开放平台; 全面开放以自然语言处理能力为核心的 NLP 基础技术平台。 参考:微信9年:张小龙指明方向,微信AI全面开放NLP能力 今天公开课上隆重介绍了...

素质云笔记 1万+

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

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

jj89929665的博客 684

ABB机器人将实时坐标发送给西门子PLC的具体方法示例

ABB机器人将实时坐标发送给西门子PLC的具体方法示例

Robot_PLC_HMI_Automation 4914

IDEA的使用指南

IDEA基于java的使用手册,可以最快速的上手,在使用中不断的丰富自己的使用技巧.

为什么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

温度PID控制PLC程序

温度PID稳定控制程序,适用于欧姆龙PLC,对其他PLC也具有很大参考价值

【大白话说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】

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

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

昨天在与别人的交流中我得知一个劝告:“设计数据库,你最好将自增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、付费专栏及课程。

余额充值