mysql中InnoDB表为什么要建议用自增列做主键

InnoDB引擎表的特点

1、InnoDB引擎表是基于B+树的索引组织表(IOT)

关于B+树

(图片来源于网上)

B+ 树的特点:

(1)所有关键字都出现在叶子结点的链表中(稠密索引),且链表中的关键字恰好是有序的;

(2)不可能在非叶子结点命中;

(3)非叶子结点相当于是叶子结点的索引(稀疏索引),叶子结点相当于是存储(关键字)数据的数据层;

2、如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择主键作为聚集索引、如果没有显式定义主键,则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引、如果也没有这样的唯一索引,则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增,这个ROWID不像ORACLE的ROWID那样可引用,是隐含的)。

3、数据记录本身被存于主索引(一颗B+Tree)的叶子节点上。这就要求同一个叶子节点内(大小为一个内存页或磁盘页)的各条数据记录按主键顺序存放,因此每当有一条新的记录插入时,MySQL会根据其主键将其插入适当的节点和位置,如果页面达到装载因子(InnoDB默认为15/16),则开辟一个新的页(节点)

4、如果表使用自增主键,那么每次插入新的记录,记录就会顺序添加到当前索引节点的后续位置,当一页写满,就会自动开辟一个新的页

5、如果使用非自增主键(如果身份证号或学号等),由于每次插入主键的值近似于随机,因此每次新纪录都要被插到现有索引页得中间某个位置,此时MySQL不得不为了将新记录插到合适位置而移动数据,甚至目标页面可能已经被回写到磁盘上而从缓存中清掉,此时又要从磁盘上读回来,这增加了很多开销,同时频繁的移动、分页操作造成了大量的碎片,得到了不够紧凑的索引结构,后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。

综上总结,如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话,这时候存取效率是最高的,也就是下面这几种情况的存取效率最高:

1、使用自增列(INT/BIGINT类型)做主键,这时候写入顺序是自增的,和B+数叶子节点分裂顺序一致;

2、该表不指定自增列做主键,同时也没有可以被选为主键的唯一索引(上面的条件),这时候InnoDB会选择内置的ROWID作为主键,写入顺序和ROWID增长顺序一致;
除此以外,如果一个InnoDB表又没有显示主键,又有可以被选择为主键的唯一索引,但该唯一索引可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况),该表的存取效率就会比较差。

《高性能MySQL》中的原话

参考:https://ruby-china.org/topics/26352

时间: 2024-10-19 15:00:17

mysql中InnoDB表为什么要建议用自增列做主键的相关文章

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键 http://imysql.com/2014/09/14/mysql-faq-why-innodb-table-using-autoinc-int-as-pk.shtml 我们先了解下InnoDB引擎表的一些关键特征: InnoDB引擎表是基于B+树的索引组织表(IOT): 每个表都需要有一个聚集索引(clustered index): 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree):

mysql的Innodb表为什么要用数字自增主键

InnoDB引擎表的特点 1.InnoDB引擎表是基于B+树的索引组织表(IOT) 关于B+树 (图片来源于网上) B+ 树的特点: (1)所有关键字都出现在叶子结点的链表中(稠密索引),且链表中的关键字恰好是有序的; (2)不可能在非叶子结点命中; (3)非叶子结点相当于是叶子结点的索引(稀疏索引),叶子结点相当于是存储(关键字)数据的数据层; 2.如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择主键作为聚集索引.如果没有显式定义主键,则InnoDB会选择第一个不包含有NU

MySQL面试题之为什么要为innodb表设置自增列做主键?

为什么要为innodb表设置自增列做主键? 1.使用自增列做主键,写入顺序是自增的,和B+数叶子节点分裂顺序一致 2.表不指定自增列做主键,同时也没有可以被选为主键的唯一索引,InnoDB就会选择内置的rowid作为主键,写入顺序和rowid增长顺序一致 所以InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话,这时候存取效率是最高 原文地址:https://www.cnblogs.com/FengGeBlog/p/10284284.html

mysql中InnoDB存储引擎的行锁和表锁

Mysql的InnoDB存储引擎支持事务,默认是行锁.因为这个特性,所以数据库支持高并发,但是如果InnoDB更新数据的时候不是行锁,而是表锁的话,那么其并发性会大打折扣,而且也可能导致你的程序出错. 而导致行锁变为表锁的情况之一就是: SQL的更新(update)或者删除(delete)语句中未使用到索引,导致在InnoDB在对数据进行相应操作的时候必须把整个表锁起来进行检索(表锁).而如果使用了索引的话,InnoDB只会通过索引条件检索数据,而只锁住索引对应的行(行锁). 下面记录一下我遇到

MySQL中innodb引擎分析(初始化)

MySQL的存储引擎是以插件形式工作的,这应该是MySQL的一大特色了吧! 依据<深入理解MySQL>的内容,5.1版本号时存储引擎的插件化都还不是彻底,确切的说是刚加入的特性.为MySQL加入一个存储引擎时,须要更改一些上层代码,零散的更改本来就有点麻烦,同一时候project也要又一次编译一次.我听别人说,已经能够不改C/C++代码就直接加入引擎了.这种话,折腾存储引擎的话就更方便了! 这段代码来自ha_innodb.cc,这是MySQL中申明存储引擎插件的标准过程.这段代码利用了宏.在p

MYSQL中InnoDB特性浅谈

许久没有更新博客,上周末放假把网易大牛姜sir的著作MYSQL技术内幕InnoDB存储引擎又翻阅了一番,对当前工作的InnoDB特性有了一些新的认识,下面谈谈自己的读后感. 1. InnoDB的体系架构由一系列后台线程,内存池和文件组成,这点与其他DB有相似之处. 在内存中划分了一块区域,即缓冲池,用来临时存放用户读写的数据页. InnoDB上对缓冲池读写数据页,刷新到磁盘等操作也使用了CHECKPOINT机制,LRU算法,这点与SQLSERVER,DB2等数据库设计一致,这里不再阐述.需要注意

MySQL中Innodb的聚簇索引和非聚簇索引

聚簇索引 数据库表的索引从数据存储方式上可以分为聚簇索引和非聚簇索引(又叫二级索引)两种.Innodb的聚簇索引在同一个B-Tree中保存了索引列和具体的数据,在聚簇索引中,实际的数据保存在叶子页中,中间的节点页保存指向下一层页面的指针.“聚簇”的意思是数据行被按照一定顺序一个个紧密地排列在一起存储.一个表只能有一个聚簇索引,因为在一个表中数据的存放方式只有一种. 一般来说,将通过主键作为聚簇索引的索引列,也就是通过主键聚集数据.下图展示了Innodb中聚簇索引的结构(图片来自<高性能MySQL

Mysql 自增列 主键

Mysql中假如有 ID Int auto_increment, CID varchar(36). 通常情况下都是 ID设置为主键. 假如要设置CID为主键.自增列ID必需是唯一索引. create table Temp ( ID bigint not null auto_increment comment '编号', CID varchar(36) not null, CreateTime datetime not null default now() comment '创建时间', uniq

mysql中innodb和myisam对比及索引原理区别(转)

InnoDB和MyISAM是很多人在使用MySQL时最常用的两个表类型,这两个表类型各有优劣,5.7之后就不一样了 1.事务和外键 InnoDB具有事务,支持4个事务隔离级别,回滚,崩溃修复能力和多版本并发的事务安全,包括ACID.如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能 MyISAM管理非事务表.它提供高速存储和检索,以及全文搜索能力.如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择 2.全文索引 I