MySQL中主键索引与聚焦索引之概念的学习教程

主键索引

主键索引，简称主键，原文是PRIMARY KEY，由一个或多个列组成，用于唯一性标识数据表中的某一条记录。一个表可以没有主键，但最多只能有一个主键，并且主键值不能包含NULL。

在MySQL中，InnoDB数据表的主键设计我们通常遵循几个原则：

采用一个没有业务用途的自增属性列作为主键；
主键字段值总是不更新，只有新增或者删除两种操作；
不选择会动态更新的类型，比如当前时间戳等。
这么做的好处有几点：

新增数据时，由于主键值是顺序增长的，innodb page发生分裂的概率降低了；可以参考以往的分享“[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键”；
业务数据有变更时，不修改主键值，物理存储位置发生变化的概率降低了，innodb page中产生碎片的概率也降低了。
MyISAM表因为是堆组织表，主键类型设计方面就可以这么讲究了。

辅助索引，就是我们常规所指的索引，原文是SECONDARY KEY。辅助索引里还可以再分为唯一索引，非唯一索引。

唯一索引其实应该叫做唯一性约束，它的作用是避免一列或多列值存在重复，是一种约束性索引。

在MyISAM引擎中，唯一索引除了key值允许存在NULL外，其余的和主键索引没有本质性区别。也就是说，在MyISAM引擎中，不允许存在NULL值的唯一索引，本质上和主键索引是一回事。

而在InnoDB引擎中，主键索引和辅助索引的区别就很大了。主键索引会被选中作为聚集索引，而唯一索引和普通辅助索引间除了唯一性约束外，在存储上没本质区别。

从查询性能上来说，在MyISAM表中主键索引和不允许有NULL的唯一索引的查询性能是相当的，在InnoDB表通过唯一索引查询则需要多一次从辅助索引到主键索引的转换过程。InnoDB表基于普通索引的查找代价更高，因为每次检索到结果后，还需要至少再多检索一次才能确认是否还有更多符合条件的结果，主键索引和唯一索引就不需要这么做了。

经过测试，对100万行数据的MyISAM做随机检索（整数类型），主键和唯一索引的效率基本一样，普通索引的检索效率则慢了30%以上。换成InnoDB表的话，唯一索引比主键索引效率约慢9%，普通索引比主键索引约慢了50%以上。

聚集索引
在MySQL中，InnoDB引擎表是（聚集）索引组织表（clustered index organize table），而MyISAM引擎表则是堆组织表（heap organize table）。

也有人把聚集索引称为聚簇索引。

当然了，聚集索引的概念不是MySQL里特有的，其他数据库系统也同样有。

简言之，聚集索引是一种索引组织形式，索引的键值逻辑顺序决定了表数据行的物理存储顺序，而非聚集索引则就是普通索引了，仅仅只是对数据列创建相应的索引，不影响整个表的物理存储顺序。

我们先来看看两种存储形式的不同之处：
简单说，IOT表里数据物理存储顺序和主键索引的顺序一致，所以如果新增数据是离散的，会导致数据块趋于离散，而不是趋于顺序。而HOT表数据写入的顺序是按写入时间顺序存储的。
IOT表相比HOT表的优势是：

范围查询效率更高；
数据频繁更新（聚集索引本身不更新）时，更不容易产生碎片；
特别适合有一小部分热点数据频繁读写的场景；
通过主键访问数据时快速可达；
IOT表的不足则有：

  • 数据变化如果是离散为主的话，那么效率会比HOT表差；

HOT表的不足有：

  • 索引回表读开销很大；
  • 大部分数据读取时随机的，无法保证被顺序读取，开销大；
  • 每张InnoDB表只能创建一个聚集索引，聚集索引可以由一列或多列组成。

上面说过，InnoDB是聚集索引组织表，它的聚集索引选择规则是这样的：

首先选择显式定义的主键索引做为聚集索引；
如果没有，则选择第一个不允许NULL的唯一索引；
还是没有的话，就采用InnoDB引擎内置的ROWID作为聚集索引；

可以看到，在这个索引结构的叶子节点中，节点key值是主键的值，而节点的value则存储其余列数据，以及额外的ROWID、rollback pointer、trx id等信息。

结合这个图，以及上面所述，我们可以知道：在InnoDB表中，其聚集索引相当于整张表，而整张表也是聚集索引。主键必然是聚集索引，而聚集索引则未必是主键。

MyISAM是堆组织表，它没有聚集索引的概念。

两者的比较

下面是一个简单的比较表

赞 (0)

相关推荐

  • 强制SQL Server执行计划使用并行提升在复杂查询语句下的性能

    强制SQL Server执行计划使用并行提升在复杂查询语句下的性能

    通过观察执行计划,发现之前的执行计划在很多大表连接的部分使用了Hash Join,由于涉及的表中数据众多,因此查询优化器选择使用并行执行,速度较快.而我们优化完的执行计划由于索引的存在,且表内数据非常大,过滤条件的值在一个很宽的统计信息步长范围内,导致估计行数出现较大偏差(过滤条件实际为15000行,步长内估计的平均行数为800行左右),因此查询优化器选择了Loop Join,且没有选择并行执行,因此执行时间不降反升. 由于语句是在存储过程中实现,因此我们直接对该语句使用一个undocument

  • 浅析SQL Server 聚焦索引对非聚集索引的影响

    浅析SQL Server 聚焦索引对非聚集索引的影响

    前言 在学习SQL 2012基础教程过程中会时不时穿插其他内容来进行讲解,相信看过SQL Server 2012 T-SQL基础教程的童鞋知道前面写的所有内容并非都是摘抄书上内容,如若是这样那将没有任何意义,学习的过程必须同时也是一个思考的过程,无论是独立思考也好还是查资料也罢都是思考而非走马观花,要不然过一段时间又会健忘.简短的内容,深入的理解. 话题 非聚集索引定义:非聚集索引也是一个B树结构,与聚集索引不同的是,B树的叶子节点存的是指向堆或聚集索引的指针.你真的理解了吗??你能举出例子吗?

  • SQLSERVER中得到执行计划的两种方式

    SQLSERVER中得到执行计划的两种方式

    得到执行计划的方式有两种: 1.一种是在指令的前面打开一些开关,让执行计划信息打在结果集里,这种方法比较适合在一个测试环境里对单个语句调优. 这些开关最常用的有 复制代码 代码如下: SET SHOWPLAN_ALL ON SET SHOWPLAN_ALL ON --(是不是reuse了一个执行计划,SQSERVERL有没有觉得缺少索引),只能在XML的输出里看到 SET STATISTICS PROFILE ON 还有如果使用SSMS的话,可以用快捷键:Ctrl+L 小写L 他会执行你的语句并

  • 浅析SQL Server中的执行计划缓存（下）

    浅析SQL Server中的执行计划缓存（下）

    在上篇文章给大家介绍了SQL Server中的执行计划缓存(上),本文继续给大家介绍sqlserver执行计划缓存相关知识,小伙伴们一起学习吧. 简介 在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法. 将执行缓存考虑在内时的流程 上篇文章中提到了查询优化器解析语句的过程,当将计划缓存考虑在内时,首先需要查看计划缓存中是否已经有语句的缓存,如果没有,才会执行编译过程,如果存在则直接利用编译好的执行计划.因

  • 浅析SQL Server中的执行计划缓存(上)

    浅析SQL Server中的执行计划缓存(上)

    简介 我们平时所写的SQL语句本质只是获取数据的逻辑,而不是获取数据的物理路径.当我们写的SQL语句传到SQL Server的时候,查询分析器会将语句依次进行解析(Parse).绑定(Bind).查询优化(Optimization,有时候也被称为简化).执行(Execution).除去执行步骤外,前三个步骤之后就生成了执行计划,也就是SQL Server按照该计划获取物理数据方式,最后执行步骤按照执行计划执行查询从而获得结果.但查询优化器不是本篇的重点,本篇文章主要讲述查询优化器在生成执行计划之

  • SQL Server中参数化SQL写法遇到parameter sniff ，导致不合理执行计划重用的快速解决方法

    SQL Server中参数化SQL写法遇到parameter sniff ，导致不合理执行计划重用的快速解决方法

    parameter sniff问题是重用其他参数生成的执行计划,导致当前参数采用该执行计划非最优化的现象.想必熟悉数据的同学都应该知道,产生parameter sniff最典型的问题就是使用了参数化的SQL(或者存储过程中使用了参数化)写法,如果存在数据分布不均匀的情况下,正常情况下生成的执行计划,在传入在分布数据较多的参数的情况下,重用了正常参数生成的执行计划,而这种缓存的执行计划并非适合当前参数的一种情况. 这种情况,在实际业务中,出现的频率还是比较高的,因为存储过程一般都是采用参数化的写法

  • SqlServer 执行计划及Sql查询优化初探

    SqlServer 执行计划及Sql查询优化初探

    网上的SQL优化的文章实在是很多,说实在的,我也曾经到处找这样的文章,什么不要使用IN了,什么OR了,什么AND了,很多很多,还有很多人拿出仅几S甚至几MS的时间差的例子来证明着什么(有点可笑),让许多人不知道其是对还是错.而SQL优化又是每个要与数据库打交道的程序员的必修课,所以写了此文,与朋友们共勉. 谈到优化就必然要涉及索引,就像要讲锁必然要说事务一样,所以你需要了解一下索引,仅仅是索引,就能讲半天了,所以索引我就不说了(打很多字是很累的,况且我也知之甚少),可以去参考相关的文章,这个网上

  • 浅析SQL Server的聚焦使用索引和查询执行计划

    浅析SQL Server的聚焦使用索引和查询执行计划

    前言 上一篇<浅析SQL Server 聚焦索引对非聚集索引的影响>我们讲了聚集索引对非聚集索引的影响,对数据库一直在强调的性能优化,所以这一节我们统筹讲讲利用索引来看看查询执行计划是怎样的,简短的内容,深入的理解. 透过索引来看查询执行计划 我们首先来看看第一个例子 1.默认使用索引 USE TSQL2012 GO SELECT orderid FROM Sales.Orders SELECT * FROM Sales.Orders 上述我们看到第2个查询的所需要的开销是第1个查询开销的3倍

  • MySQL中主键索引与聚焦索引之概念的学习教程

    MySQL中主键索引与聚焦索引之概念的学习教程

    主键索引 主键索引,简称主键,原文是PRIMARY KEY,由一个或多个列组成,用于唯一性标识数据表中的某一条记录.一个表可以没有主键,但最多只能有一个主键,并且主键值不能包含NULL. 在MySQL中,InnoDB数据表的主键设计我们通常遵循几个原则: 采用一个没有业务用途的自增属性列作为主键: 主键字段值总是不更新,只有新增或者删除两种操作: 不选择会动态更新的类型,比如当前时间戳等. 这么做的好处有几点: 新增数据时,由于主键值是顺序增长的,innodb page发生分裂的概率降低了:可以

  • MySQL中主键与rowid的使用陷阱总结

    前言 大家在MySQL中我们可能听到过rowid的概念,但是却很难去测试实践,不可避免会有一些疑惑,比如: 如何感受到rowid的存在: rowid和主键有什么关联关系: 在主键的使用中存在哪些隐患: 如何来理解rowid的潜在瓶颈并调试验证. 本文要和大家一起讨论这几个问题,测试的环境基于MySQL 5.7.19版本. 问题1.如何感受到rowid的存在 我们不妨通过一个案例来进行说明. 记得有一天统计备份数据的时候,写了一条SQL,当看到执行结果时才发现SQL语句没有写完整,在完成统计工作之

  • 快速理解MySQL中主键与外键的实例教程

    主键与外键的关系,通俗点儿讲,我现在有一个论坛,有两张表,一张是主贴 thread,一张是回帖 reply 先说说主键,主键是表里面唯一识别记录的字段,一般是帖子id,体现在访问的时候,例如是 thread.php?id=1   表示我要访问的是帖子id是1 的帖子- 再来说说外键,当我们删除某个帖子的时候,需要执行另一个操作,就是删除所有回帖,如果正常情况下,我们需要执行两次delete操作(thread和 reply),这时候如果存在外键,例如,在reply 表里面建立一个指向thread表

  • MySQL中主键为0与主键自排约束的关系详解(细节)

    前言 本文主要介绍了关于MySQL主键为0与主键自排约束的关系,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 开始不设置主键表的设计如下: 如果id的位置有好几个0的话:设置主键并且自动排序时,0会从1开始递增: Insert 进去 id = 0的数据,数据会从实际的行数开始增加,和从0变化不一样: 现在主键是没有0的,如果把某个id改成0的话,0不会变!直接会进行排序: 再insert一个id=0的看看,居然还是跟刚才一样直接跟行数相关! 再重置一下自动排序,看看这个0会不

  • MySQL中的全表扫描和索引树扫描 的实例详解

    MySQL中的全表扫描和索引树扫描 的实例详解

    目录 引言 实例 引言 在学习mysql时,我们经常会使用explain来查看sql查询的索引等优化手段的使用情况.在使用explain时,我们可以观察到,explain的输出有一个很关键的列,它就是type属性,type表示的是扫描方式,代表 MySQL 使用了哪种索引类型,不同的索引类型的查询效率是不一样的. 在type这一列,有如下一些可能的选项: system:系统表,少量数据,往往不需要进行磁盘IOconst:常量连接eq_ref:主键索引(primary key)或者非空唯一索引(u

  • MySQL的主键命名策略相关

    MySQL的主键命名策略相关

    最近在梳理数据生命周期管理的细节时,发现了一个小问题,那就是MySQL的主键命名策略,似乎会忽略任何形式的自定义命名. 也就意味着你给主键命名为idx_pk_id这种形式,在MySQL里面会统一按照PRIMARY来处理. 当然我们可以在这个基础之上做一些拓展和补充. 首先来复现下问题,我们连接到数据库test,然后创建表test_data2. mysql> use test mysql> create table test_data2 (id int ,name varchar(30)); Q

  • 详解MySQL的主键查询为什么这么快

    详解MySQL的主键查询为什么这么快

    目录 1. 初探InnoDB行格式(ROW_FORMAT) 2. 引入InnoDB页 3. 数据页的结构 3.1 用户记录是如何存放的 3.2 番外:为什么推荐使用自增ID作为主键,而不推荐使用UUID? 3.3 数据页自带的两条伪记录 3.4 数据页中主键的高效查询方案 4. 重要!数据页的其他字段 这篇文章会让大家清楚地明白: 什么是InnoDB行格式?InnoDB页是什么? InnoDB页和InnoDB行格式都有哪些字段信息? 为什么推荐使用自增ID作为主键,而不推荐使用UUID? Inn

  • 关于数据库设计中主键问题的思考

    在基于关系型数据库设计时候,通常要为每张表指定一个主键,所谓主键就是能够唯一标识表中某一行记录的属性或属性组,一个表只能有一个主键,但可以有多个候选索引.因为主键可以唯一标识某一行记录,所以可以确保执行数据更新.删除.修改时不出现错误.当然,其它字段可以辅助我们在执行这些操作时消除共享冲突,不是本文讨论的重点,不再赘述.主键除了上述作用外,常常与外键构成参照完整性约束,防止出现数据不一致.所以数据库在设计时,主键起到了很重要的作用.常见的数据库主键选取方式有: 自动增长式.手动增长式 .Uniq

  • mysql非主键自增长用法实例分析

    mysql非主键自增长用法实例分析

    本文实例讲述了mysql非主键自增长用法.分享给大家供大家参考,具体如下: mysql并非只有主键才能自增长,而是设为键的列就可以设置自增长.   如下: CREATE TABLE t1 ( id INT, col1 INT auto_increment NOT NULL ); 结果如下: 如果把col1列设为键,就可以创建自增. CREATE TABLE t1 ( id INT, col1 INT auto_increment NOT NULL, key(col1) ); 结果如下: 如果我们

  • Mysql 增加主键或者修改主键的sql语句操作

    添加表字段 alter table table1 add transactor varchar(10) not Null; alter table table1 add id int unsigned not Null auto_increment primary key 修改某个表的字段类型及指定为空或非空 alter table 表名称 change 字段名称 字段名称 字段类型 [是否允许非空]; alter table 表名称 modify 字段名称 字段类型 [是否允许非空]; alt

随机推荐