聚集索引

一、索引概念 1.什么是索引： 索引在MySQL中也叫做“键”，是存储引擎用于快速找到记录的一种数据结构。 索引就是一种数据结构，类似于书的目录。意味着以后再查数据应该先找目录再找数据，而不是用翻页的方式查询数据 本质都是：通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件（比如书没目录就只能随机翻），也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据（永远就是按照索引去找，不用正着翻反着翻了）。 补充：innodb引擎只有表结构和数据两个文件夹，不像myisam三个文件有单独的索引文件，表结构中不可能放别的，所以索引是和数据放在一个文件中的 2.三种索引（键）： primary key unique key index key 注意foreign key不是用来加速查询用的，不在我们研究范围之内, 上面三种key前两种除了有加速查询的效果之外还有额外的约束条件(primary key:非空且唯一，unique key:唯一)，而index key没有任何约束功能只会帮你加速查询 3.索引的影响（缺点）: 在表中有大量数据的前提下，创建索引速度会很慢 （例如一本书特别厚，你需要一页一页去查看有什么内容一页一页建目录，所以如果数据量特别大时你命令敲完之后，终端会卡很长一段时间去疯狂的建索引） 在索引创建完毕后

一张表就是一本新华字典。 聚集索引就是页码，在这个页码上有真正的数据，并且字典就是按照页码从小到达来印刷和装订的。 非聚集索引就是按照拼音检索，按照部首检索，按照笔画数检索，可以理解成3个非聚集索引。 这些非聚集索引上会有一个页号，但是真正的内容需要你翻开那一页才能看到。 包含性的非聚集索引就是在普通的非聚集索引的基础上，在本来只标记页号的地方还记录了一些别的东西，这样你不用翻到那一页，也能看到一小部分那一页的内容。 所以非聚集索引的本质就是一份额外的存储，而维护非聚集索引也需要成本，非聚集索引不是万能药。。。 来源： https://www.cnblogs.com/xuyuchn/p/11394924.html

什么是索引 　　相当于书目录，用于快速检索 　　优点 　　　　提高数据检索效率 　　　　提高表间的JOIN效率 　　　　利用唯一性索引，保证数据的唯一性 　　　　提高排序和分组效率 　　缺点 　　 　　消耗更多物理存储 　　　　数据变更时，索引也需要更新，降低更新效率 　　哪种情况下应该创建索引 　　　　经常检索的列 　　　　经常用于表连接的列 　　　　经常排序/分组的列 　　索引不使用建议 　　　　基数很低的列 　　　　更新频繁但检索不频繁的列 　　　　BLOB/TEXT 等长内容列 　　　　很少用于检索的列 二分查找 　　折半查找，binary search 　　一种在有序数组中查找某一特定元素的搜索算法 　　二分查找发的优点是比较次数少，查找速度快，平均性能好，其缺点是要求待查表为有序表，且插入删除困难，因此，二分查找法适用于不经常变动而查询频繁的有序列表 二叉树，binary tree 　　二叉树是每个节点至多只有二颗子树（不存在度大于2的节点），二叉树的子树有左右有序之分，次序不能颠倒。 　　 平衡树，平衡二叉树， self-balancing binary search tree 　　改进的二叉查询树。一般的二叉查找树的查询复杂度是跟目标节点到树根的距离（即深度）有关，因此当节点的深度普遍较大时，查询的均摊复杂度会上升，为了更高效的查询，有了平衡树 　　平衡二叉树的特点

什么是索引？ 索引在mysql中也叫是一种'键',是存储引擎用于快速找到记录的一种数据结构.索引对于良好的性能非常关键,尤其是当表中的数据量越来越大时,索引对于性能的影响越发重要. 索引优化应该是对查询性能优化最有效的手段了。索引能够轻易将查询性能提高好几个数量级。 索引相当于字典的音序表，如果要查某个字，如果不使用音序表，则需要从几百页中逐页去查。 索引原理 　　 索引的目的在于提高查询效率,本质都是不断的缩小查询范围来得到我们想要查询的结果.同时把随机的时间变成顺序的事件,　 索引的数据结构 树 树状图是一种 数据结构 ，它是由n（n>=1）个有限结点组成一个具有层次关系的 集合 。把它叫做“树”是因为它看起来像一棵倒挂的树，也就是说它是根朝上，而叶朝下的。 它具有以下的特点：每个结点有零个或多个子结点；没有父结点的结点称为根结点；每一个非根结点有且只有一个父结点；除了根结点外，每个子结点可以分为多个不相交的子树 根结点 : A 父节点 : A是B,C的父节点 叶子节点：D,E是叶子节点 树的深度/树的高度：高度为3 B+树 每次查找数据时把磁盘IO次数控制在一个很小的数量级，最好是常数数量级。那么我们就想到如果一个高度可控的多路搜索树是否能满足需求呢？就这样，b+树应运而生（B+树是通过二叉查找树，再由平衡二叉树，B树演化而来）。 b+树性质 1 .索引字段要尽量的小

目录 一, 什么是索引 二, 索引的数据结构 三, Mysql索引管理 四, 正确使用索引 五, 联合索引与覆盖索引 六, 补充 一, 什么是索引 为什么要有索引? 一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，在生产环境中，我们遇到最多的，也是最容易出问题的，还是一些复杂的查询操作，因此对查询语句的优化显然是重中之重。说起加速查询，就不得不提到索引了。 什么是索引？ 索引在MySQL中也叫是一种“键”，是 存储引擎用于快速找到记录的一种数据结构 。索引对于良好的性能非常关键，尤其是当表中的数据量越来越大时，索引对于性能的影响愈发重要。索引优化应该是对查询性能优化最有效的手段了。索引能够轻易将查询性能提高好几个数量级。索引相当于字典的音序表，如果要查某个字，如果不使用音序表，则需要从几百页中逐页去查。 有哪些索引? 索引种类 : memory(hash索引); (innodb/myisam)-b+tree(聚集索引 辅助索引) mysql中有哪些索引? primary key 主键索引\联合主键索引 unique key 唯一索引\联合唯一索引 index key 普通索引\联合索引 二, 索引的数据结构 本质是: 通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是说，有了这种索引机制

目录 一、树 二、B+树 2.1 B+树性质 三、聚集索引和辅助索引 3.1 聚集索引 3.2 辅助索引 3.3 聚集索引和非聚集索引的区别 四、再看B+树 4.1 B+树的插入操作 4.2 B+树的删除操作 一、树 树状图是一种 数据结构 ，它是由n（n>=1）个有限结点组成一个具有层次关系的集合。把它叫做“树”是因为它看起来像一棵倒挂的树，也就是说它是根朝上，而叶朝下的。 它具有以下的特点：每个结点有零个或多个子结点；没有父结点的结点称为根结点；每一个非根结点有且只有一个父结点；除了根结点外，每个子结点可以分为多个不相交的子树 根结点：A 父节点：A是B，C的父节点 叶子节点：D，E是叶子节点 树的深度/树的高度：高度为3 二、B+树 前面讲了索引的基本原理，数据库的复杂性，又讲了操作系统的相关知识，目的就是让大家了解，任何一种数据结构都不是凭空产生的，一定会有它的背景和使用场景，我们现在总结一下，我们需要这种数据结构能够做些什么，其实很简单，那就是：每次查找数据时把磁盘IO次数控制在一个很小的数量级，最好是常数数量级。那么我们就想到如果一个高度可控的多路搜索树是否能满足需求呢？就这样，b+树应运而生（B+树是通过二叉查找树，再由平衡二叉树，B树演化而来）。 2.1 B+树性质 索引字段要尽量的小： 通过上面的分析，我们知道IO次数取决于b+数的高度h，假设当前数据表的数据为N

这篇接着我们的索引学习系列，这次主要来分享一些有关聚集索引的问题。上一篇 SQL索引学习-索引结构 主要是从一些基础概念上给大家分享了我的理解，没有实例，有朋友就提到了聚集索引的问题，这里列出来一下： 其实，我想知道的就是对于一个大数据量的表，我应该用哪种索引，各有什么优缺点。如果能带一两个实例，就更perfect了。 看过很多这样文章，但具体还是不知道如何设计表和优化，比如：聚集和非聚集， 唯一与主键, 设计表事该如何取舍。应该有示例说明,这更容易理解，只是概念即使理解了也不容易消化。 上面两位朋友的问题有一个共同特点，就是希望有示例，因为这样容易让他们更加容易理解。但从我的角度来讲，有示例只能给你提供一个参考而已，够不成是否容易消化的关键因素，最好的办法是，通过自己的理解，自己有能力去做相应的实验，这样效果才是最好的，你也会发现更多的问题，每个项目都有自己的特点，所以性能优化这块也是需要因地制宜的。 聚集索引的存储结构 聚集索引的特点 索引的数据以及实际物理数据存储于同一张表中，这与非聚集索引不相同 物理数据或者叫关键字出现在叶子结点的双向链表中 非叶子结点不可能出现物理数据或者叫关键字 非叶子结点相当于叶子结点的索引 B+树的结构 1,2,3,4,5,6,7为Key d1,d2,d3,d4,d5,d6,d7分别是数据 红色框是链接下一节点的指针

前一阵无意中和同事讨论过一个SQL相关的题( 通过一个小问题来学习SQL关联查询 )，很惭愧一个非常简单的问题由于种种原因居然没有回答正确，数据库知识方面我算不上技术好，谈起SQL知识的学习我得益于2008年进的一家公司，有几个DBA技术相当专业，正好手上有一个项目遇到了一些数据库查询性能问题，就试着想办法优化，于是自己将相法和DBA沟通后，居然得到了他们的赞同，让我信心大增，后来一段时间我又主动找他们聊了一些其它的知识，所以在数据库索引这块我算是相对一般的.net程序员要更加有见解一些。当时我们部门由于分工的不同，部门20多人基本上工作中从来不和SQL打交道，后台的接口都由其它部门来完成了，我们注意的 业务逻辑，所以有一些完全不懂SQL的程序员。之后的四年我大部分都是做一些通用平台架构方面的工作，也比较少直接接触SQL，直到后来换了公司，特别是去年开始由于项目性质的变化，我开始慢慢又开始接触SQL。 工作时间的长短在某种程度上能决定一个人的技术水平，但往往技术水平和实际工作的产出不一定成正比。比如我上面提到那个SQL问题，很多有经验的程序员在第一个答案中往往回答错误，但他确实能将项目做好，因为大家平时观注的还是结果，只要结果出来了比什么都强，至于为什么出这样的结果一般也就不会多做分析研究。这种形式呢，对那些对技术提升没有强烈要求的人来讲，已经够用了，多试几次

出处原文： 1分钟了解MyISAM与InnoDB的索引差异 数据库的索引分为 主键索引 （Primary Inkex）与 普通索引 （Secondary Index）。InnoDB和MyISAM是怎么利用B+树来实现这两类索引，其又有什么差异呢？这是今天要聊的内容。 一，MyISAM的索引 MyISAM的 索引与行记录是分开存储的 ，叫做 非聚集索引 （UnClustered Index）。 其主键索引与普通索引没有本质差异： 有连续聚集的区域 单独存储行记录 主键索引的叶子节点，存储主键，与对应行记录的 指针 普通索引的叶子结点，存储索引列，与对应行记录的 指针 画外音：MyISAM的表可以没有主键。 主键索引与普通索引是两棵独立的索引B+树，通过索引列查找时，先定位到B+树的叶子节点，再通过指针定位到行记录。 举个例子，MyISAM： t(id PK, name KEY, sex, flag); 表中有四条记录： 1, shenjian, m, A 3, zhangsan, m, A 5, lisi, m, A 9, wangwu, f, B 其B+树索引构造如上图： 行记录单独存储 id为PK，有一棵id的索引树，叶子指向行记录 name为KEY，有一棵name的索引树，叶子也指向行记录 二、InnoDB的索引 InnoDB的 主键索引与 行记录是存储在一起的，故叫做

DECLARE @zindex_sql NVARCHAR(max); SET @zindex_sql = N''; SELECT @zindex_sql = @zindex_sql + N'CREATE ' + CASE WHEN r.is_unique=1 THEN N'UNIQUE' ELSE N'' END + N' NONCLUSTERED INDEX [' + r.INDEX_name + N'] ON [' + r.schemas_name + '].[' + r.tablename + '] ' + r.index_fields + CASE WHEN r.include_fields<>N'' THEN N' INCLUDE ' + r.include_fields ELSE N'' END + N' ON [PRIMARY];' FROM ( SELECT b.object_id AS tid,b.schemas_name, b.name AS tablename,c.name as INDEX_name, REPLACE(REPLACE(REPLACE((SELECT N'[' + y.name + N']' + CASE WHEN x.is_descending_key=1 THEN N' DESC' ELSE N'' END AS field_name