聚集索引

主键（PRIMARY KEY） 表通常具有包含唯一标示表中每一行的值的一列或者一组列。这样的一列或者多列称为表的主键（PK），用于强制表的尸体完整性。在创建或者修改表时，您可以通过定义PK约束来创建主键。 一个表只能有一个PK约束，并且PK约束中的列不能接受空值。由于PK约束可以保证数据的唯一性，因此经常对标识列定义这种约束。 如果为表指定了PK约束，数据库引擎将通过为主键列创建唯一索引来强制数据的唯一性。当在查询中使用主键时，此索引还可以用来对数据进行快速访问。因此，所选的主键必须遵守创建唯一索引的规则。 创建主键时，数据库引擎会自动创建唯一的索引来强制实施PK约束的唯一性要求。如果表中不存在狙击索引或未显示指定非聚集索引，则将创建唯一的聚集索引以强制实施PK约束。 聚集索引 聚集索引给予数据行的兼职在表内排序和存储这些数据行。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。 每个表几乎都对列定义聚集索引来实现下列功能： 可用于经常使用的查询。 提供高度唯一性。 两者的比较 主键 聚集索引 用途 强制表的实体完整性 对数据行的排序，方便查询用 一个表多少个 一个表最多一个主键 一个表最多一个聚集索引 是否允许多个字段来定义 一个主键可以多个字段来定义 一个索引可以多个字段来定义 是否允许null值 如果要创建的数据列中数据存在null，无法创建主键

微软官网上的解释： 索引是与表或视图关联的磁盘上结构，可以加快从表或视图中检索行的速度。 索引包含由表或视图中的一列或多列生成的键。 这些键存储在一个结构（B 树）中，使 SQL Server 可以快速有效地查找与键值关联的行。 表或视图可以包含以下类型的索引： 聚集 聚集索引根据数据行的键值在表或视图中排序和存储这些数据行。 索引定义中包含聚集索引列。 每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。 只有当表包含聚集索引时，表中的数据行才按排序顺序存储。 如果表具有聚集索引，则该表称为聚集表。 如果表没有聚集索引，则其数据行存储在一个称为堆的无序结构中。 非聚集 非聚集索引具有独立于数据行的结构。 非聚集索引包含非聚集索引键值，并且每个键值项都有指向包含该键值的数据行的指针。 从非聚集索引中的索引行指向数据行的指针称为行定位器。 行定位器的结构取决于数据页是存储在堆中还是聚集表中。 对于堆，行定位器是指向行的指针。 对于聚集表，行定位器是聚集索引键。 可以向非聚集索引的叶级添加非键列以跳过现有的索引键限制，并执行完整范围内的索引查询。 聚集索引和非聚集索引都可以是唯一的。 这意味着任何两行都不能有相同的索引键值。 另外，索引也可以不是唯一的，即多行可以共享同一键值。 实际上，可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引

在 SQL Server 中，为了查询性能的优化，有时我们就需要对数据表通过建立索引的方式，目的主要是根据查询要求，迅速缩小查询范围，避免全表扫描。 索引有两种类型，分别是聚集索引(clustered index，也称聚类索引、簇集索引)和非聚集索引(nonclustered index，也称非聚类索引、非簇集索引)。 聚集索引在一个表中只能有一个，默认情况下在主键建立的时候创建，它是规定数据在表中的物理存储顺序，我们也可以取消主键的聚集索引，所以必须考虑 数据库 可能用到的查询类型以及使用的最为频繁的查询类型，对其最常用的一个字段或者多个字段建立聚集索引或者组合的聚集索引，它就是SQL Server会在物理上按升序(默认)或者降序重排数据列，这样就可以迅速的找到被查询的数据。 非聚集索主要是 数据存储 在 一个地方，索引存储在另一个地方，索引带有指针指向数据的存储位置。索引中的项目按索引键值的顺序存储，而表中的信息按另一种顺序存储。可以在一个表格中 使用高达249个非聚集的索引，在查询的过程中先对非聚集索引进行搜索，找到数据值在表中的位置，然后从该位置直接检索数据。这使非聚集索引成为精确匹配 查询的最佳方法，因为索引包含描述查询所搜索的数据值在表中的精确位置的条目。 所以我们在选择创建聚集索引的时候要注意以下几个方面： 1) 对表建立主键时，就会为主键自动添加了聚集索引

索引 什么是索引？ 索引是一种磁盘上的数据结构，建立在表或视图的基础上。使用索引可以使数据的获取更快更高校，也会影响其他的一些性能，如插入或更新等。 索引主要分为两种类型：聚集索引和非聚集索引。 字典的目录就是一个索引，按照拼音查询想要的字就是聚集索引（物理连续，页码与目录一一对应），偏旁部首就是一个非聚集索引（逻辑连续，页码与目录不连续）。 聚集索引存储记录是物理上连续存在的，而非聚集索引是逻辑上的连续，物理存储并不连续。 聚集索引一个表中只能有一个，而非聚集索引一个表中可以有多个。 索引的利弊 使用索引是为了避免全表扫描，因为全表扫描是从磁盘上读取表的每一个数据页，如果有索引指向数据值，则只需要读少次数的磁盘就可以。 带索引的表在数据库中占用更多的空间，同样增、删、改数据的命令所需时间会更长。 索引的存储机制 书中的目录是一个字词以及所在的页码列表，数据库中的索引是表中的值以及各值存储位置的列表。 聚集索引是在数据库中新开辟一个物理空间，用来存放他排列的值，当有新数据插入时，他会重新排列整个物理存储空间。 非聚集索引只包含原表中的非聚集索引的列和指向实际物理表的一个指针。 数据表的基本结构 当一个新的数据表创建时，系统将在磁盘中分配一段以8k为单位的连续空间。当一个8k用完的时候，数据库指针会自动分配一个8k的空间，每个8k的空间称为一个数据页，并分配从0-7的页号

自从两年前了解到的索引以来的，就一直想写一篇有关索引的文章。然而我是个拖延癌症患者，一拖就是两年，不愧是我。该篇文章算是自己的笔记，欢迎批评。 概述 索引是什么？很多书和文章都会使用图书的目录来类比。目录的目的就是用方便我们查找具体内容的位置，具体的章节的范围。与此类似，MySQL中索引的用途是帮助我们加速查询以及排序。 在InnoDB中的索引类型有哈希索引、B+树索引、全文索引。哈希索引在InnoDB中设计为自适应的，不展开讨论。在InnoDB1.12之后有了全文索引，也是应用倒排，还没踩过坑(据说不支持中文)，有时间可以研究一下。 本篇主要讨论B+树索引。 B+树 学习MySQL的索引，必须得先了解其原理，否则很多问题将一头雾水。下文将讲述索引数据结构的原理，而不涉及其复杂的具体实现。 在谈B+树之前，不妨先思考，为什么索引能加快查询？为什么要用B+树作为索引而不用B树？哈希索引查询复杂度为O(1)为什么又不用哈希索引？ BST和AVL 在了解B树和B+树之前，先了解一下二叉搜索树(BST)和平衡二叉树(AVL)。 在顺序存储结构中(如数组)，最快的情况是第一个就是目标值，最坏的情况是最后一个是目标值，假设有n个元素，用大O标记法平均的时间复杂度为O(n)。 使用二叉搜索树可以有效的优化搜索时间。利用二叉搜索树的特性左子节点比父节点小、右子节点比父节点大

有些人可能对主键和聚集索引有所混淆，其实这两个是不同的概念，下面是一个简单的描述。不想看绕口文字者，直接看两者的对比表。尤其是最后一项的比较。 主键（PRIMARY KEY ） 来自MSDN的描述： 表通常具有包含唯一标识表中每一行的值的一列或一组列。这样的一列或多列称为表的主键 (PK)，用于强制表的实体完整性。在创建或修改表时，您可以通过定义 PRIMARY KEY 约束来创建主键。 一个表只能有一个 PRIMARY KEY 约束，并且 PRIMARY KEY 约束中的列不能接受空值。由于 PRIMARY KEY 约束可保证数据的唯一性，因此经常对标识列定义这种约束。 如果为表指定了 PRIMARY KEY 约束，则 SQL Server 2005 数据库引擎 将通过为主键列创建唯一索引来强制数据的唯一性。当在查询中使用主键时，此索引还可用来对数据进行快速访问。因此，所选的主键必须遵守创建唯一索引的规则。 创建主键时，数据库引擎 会自动创建唯一的索引来强制实施 PRIMARY KEY 约束的唯一性要求。如果表中不存在聚集索引或未显式指定非聚集索引，则将创建唯一的聚集索引以强制实施 PRIMARY KEY 约束。 聚集索引 聚集索引基于数据行的键值在表内排序和存储这些数据行。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。 每个表几乎都对列定义聚集索引来实现下列功能：

本文出处： http://www.cnblogs.com/wy123/p/7374078.html （保留出处并非什么原创作品权利，本人拙作还远远达不到，仅仅是为了链接到原文，因为后续对可能存在的一些错误进行修正或补充，无他） ICP优化原理 Index Condition Pushdown (ICP)，也称为索引条件下推，体现在执行计划的上是会出现Using index condition（Extra列，当然Extra列的信息太多了，只能做简单分析） ICP原理通俗讲就是，查询过程中，直接在查询引擎层的API获取数据的时候实现"非直接索引"过滤条件的筛选，而不是查询引擎层查询出来之后在Server层筛选。 换句话说就是ICP在获取数据的同时实现了where的次选条件中无法直接使用索引的情况下的筛选，避免了没有ICP优化的时候分两个步骤的实现（获取数据的过程没有做次选条件的过滤） 如果是非ICP优化查询的话，是两步，第一步是获取数据，第二步是获取的数据进行条件筛选。 显然，相比后者，前者可以一步实现索引的查找Seek+filter，效率上更高。 适应的场景： ICP的优化策略可用于range、ref、eq_ref、ref_or_null 类型的访问数据方法 其实没有实例不太好理解这种优化策略，还是举两个实际列子吧。 ICP优化实例 第一个例子在网上非常多，也非常容易理解

存储引擎都是作用在表上的 MyISAM索引文件和数据文件是分离的（非聚集）最终一个表会形成3个文件 例如表名叫 aa,形成的3个文件分别叫aa.frm(存储表的结构信息，就是有哪些字段等信息)，aa.MYD(存储数据)，aa.MYI(存储索引文件) InnoDB索引实现（聚集） InnoDB的表最终会形成2个文件，bb.frm(存储表的结构信息，就是有哪些字段等信息),bb.idb(索引和数据) 来源： CSDN 作者： softwareDragon 链接： https://blog.csdn.net/qq_33348135/article/details/104435383

一、索引 在之前，我对索引有以下的认知： 索引可以加快数据库的检索速度 表经常进行 INSERT/UPDATE/DELETE操作就不要建立索引了，换言之：索引会降低插入、删除、修改等维护任务的速度。 -索引需要占物理和数据空间。 了解过索引的最左匹配原则 知道索引的分类：聚集索引和非聚集索引 Mysql支持Hash索引和B+树索引两种 看起来好像啥都知道，但面试让你说的时候可能就GG了： 使用索引为什么可以加快数据库的检索速度啊？ 为什么说索引会降低插入、删除、修改等维护任务的速度。 索引的最左匹配原则指的是什么？ Hash索引和B+树索引有什么区别？主流的使用哪一个比较多？InnoDB存储都支持吗？ 聚集索引和非聚集索引有什么区别？ … 1.1聊聊索引的基础知识 首先Mysql的基本存储结构是页(记录都存在页里边)： 各个数据页可以组成一个双向链表 而每个数据页中的记录又可以组成一个单向链表 每个数据页都会为存储在它里边儿的记录生成一个页目录，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录 以其他列(非主键)作为搜索条件：只能从最小记录开始依次遍历单链表中的每条记录。 所以说，如果我们写 select*fromuserwhereusername='Java3y’这样没有进行任何优化的sql语句

############### 索引介绍 ############## """ 1. 索引介绍 需求: 一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，在生产环境中，我们遇到最多的， 也是最容易出问题的，还是一些复杂的查询操作，因此对查询语句的优化显然是重中之重。 说起加速查询，就不得不提到索引了。 索引: 简单的说,相当于图书的目录,可以帮助用户快速的找到需要的内容. 在MySQL中也叫做“键”，是存储引擎用于快速找到记录的一种数据结构。能够大大提高查询效率。 特别是当数据量非常大，查询涉及多个表时，使用索引往往能使查询速度加快成千上万倍. 本质: 索引本质：通过不断地缩小想要获取数据的范围来筛选出最终想要的结果， 同时把随机的事件变成顺序的事件，也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。 """ ############### 索引方法 ############## """ 2.索引方法 1. B+TREE 索引 B+树是一种经典的数据结构，由平衡树和二叉查找树结合产生，它是为磁盘或其它直接存取辅助设备而设计的一种平衡查找树， 在B+树中，所有的记录节点都是按键值大小顺序存放在同一层的叶节点中，叶节点间用指针相连，构成双向循环链表， 非叶节点（根节点、枝节点）只存放键值，不存放实际数据。 注意:通常其高度都在2