聚集索引

聚集索引扫描，首先我们知道数据它是以索引键为叶节点排列起来的树形数据结构，表中每行的数据都附属在索引键中，对这样的表进行数据查找时，最快的方式当然是“聚集索引查找”。什么情况下才是“聚集索引扫描”呢？是当你要查找的数据的条件字段上没有索引时，此时查询执行器将对整个表中的数据挨个的进行读取确认符合查询条件的数据，但当该表上有字段设有聚集索引时，该扫描过程称之为“聚集索引扫描",相反的情况是当该表上没有一个字段设有”聚集索引“时，该扫描过程称之为”表扫描“。其实他们本质上的过程都是一样的，就是挨个的获取表中每一行的数据，确认满足符合条件的数据的过程。从性能上看也几乎是一样的。 表扫描，表中的数据是以”堆“的形式存放起来的，也就是该表在插入一条新数据时，不用考虑这条新数据应该逻辑上放在哪个位置，只需知道它前一条数据的位置，放在它的后面即可，这里要注意一点，就是大家千万不要以为以聚集索引存放的数据在物理磁盘上也是顺序存放的哟！它们以块的方式存放在磁盘上的随机位置，只是使用链表的方式通过指针指示其前驱和后继节点的位置。这其中的道理，大家悟悟吧！原因很简单，假设聚集索引表在磁盘上数据存放是先后聚集在一起的，那么当一条中间节点的数据插入到一个靠前的位置时，那么岂不是要移动几万或是几亿的数据向磁盘的后位置去。那是太可怕了。 我们对于聚集索引扫描和表扫描比较容易理解的

MySQL认识索引 什么是索引？ 索引在MySQL中也叫是一种“键”，是存储引擎用于快速找到记录的一种数据结构。索引对于良好的性能 非常关键，尤其是当表中的数据量越来越大时，索引对于性能的影响愈发重要。 索引优化应该是对查询性能优化最有效的手段了。索引能够轻易将查询性能提高好几个数量级。 索引相当于字典的音序表，如果要查某个字，如果不使用音序表，则需要从几百页中逐页去查。 索引的原理 索引原理 索引的目的在于提高查询效率，与我们查阅图书所用的目录是一个道理：先定位到章，然后定位到该章下的一个小节，然后找到页数。相似的例子还有：查字典，查火车车次，飞机航班等 本质都是：通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。 数据库也是一样，但显然要复杂的多，因为不仅面临着等值查询，还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段查询呢？最简单的如果1000条数据，1到100分成第一段，101到200分成第二段，201到300分成第三段......这样查第250条数据，只要找第三段就可以了，一下子去除了90%的无效数据。但如果是1千万的记录呢

聚集索引不是一种单独的索引类型，而是一种存储数据方式。其具体细节依赖于实现方式，但是InnoDB的聚集索引实际上在同样的结构中保存了B-Tree索引和数据行。 当表有聚集索引的时候，它的数据行实际保存在索引的叶子页中。术语“聚集”指实际的数据行和相关的键值都保存在一起。每个表只能有一个聚集索引，因为不能一次把行保存在两个地方。（但是，覆盖索引可以模拟多个聚集索引） 当前，SolidDB和InnoDB是唯一支持聚集索引的存储引擎。InnoDB按照主键进行聚集，如果没有定义主键，InnoDB会试着使用唯一的非空索引来代替。如果没有这种索引，InnoDB就会定义隐藏的主键然后在上面进行聚集。 聚集主键有助于性能，但是它也能导致严重的性能问题。 优点： 1.可以把相关数据保存在一起。 2.数据访问快。聚集索引把索引和数据都保存到同一棵B-Tree中，因此从聚集索引中取得数据通常在非聚集索引进行查找要快。 3.使用覆盖索引的查询可以使用包含在叶子节点中的主键值 如果表和查询可以使用它们，这些优点能极大地提高性能。 缺点： 1.聚集能最大限度地提升I/O密集负载的性能。如果数据能装入内存，那么其顺序也就无怕谓了，这样聚集就没什么用处。 2.插入速度严重依赖于插入顺序。按照主键的顺序插入行是把数据装入InnoDB表最快的方法。如果没有按照主键顺序插入数据，那么在插入之后最好使用OPTIMIZE

innodb 聚集索引和普通索引 Innodb 聚集索引是按照主键（primarykey）进行聚集,被索引的列其实是主键列,如果没定义主键,Innodb会试着使用唯一非空索引Unique Index来代替,如果还找不到,Innodb就会定义隐藏主键然后在上面进行索引聚集。出了主键的聚集索引,其他索引(普通索引)中不会保存行的物理位置,而是保存主键的值,所以通过"二级索引"进行查找是先找到主键,再找到行,要进行二次索引查找。 组合索引和单列索引 组合索引在多列上创建，单列索引在一个列上创建。 查询使用索引的条件不同一般组合索引需要按照“最左前缀”来执行查询，并不是每个列都需要覆盖，只是从左边的列开始组合。 例如有索引key(a,b,c) where a=xx and b=xx and c=xxx 此语句可以用到索引 where b=xx and a=xx and c=xxx 同上，顺序没有关系，同样能用到索引 where a=xx and b=xx 可以用到索引 where a=xx and c=xx 可以用到索引 where b=xx and c=xx 用不到索引 where b=xx 用不到索引 where c=xx 用不到索引 在性能方面，如果查询既能满足单列索引，又能满足多列索引，那么通过组合索引能够加快查询的速度

聚集（clustered）索引，也叫聚簇索引。 定义：数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引 解释：就像字典根据A~Z去查汉字。 数据行的物理顺序与列值的 顺序相同 ，如果我们查询id比较靠后的数据，那么这行数据的地址在磁盘中的物理地址也会比较靠后。而且由于物理排列方式与聚集索引的顺序相同，所以也就只能建立一个聚集索引了。 非聚集（uncustered）索引 定义：该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同，一个表中可以拥有多个非聚集索引 。 除了聚集索引以外的索引都是非聚集索引，只是人们想细分一下非聚集索引，分成普通索引，唯一索引，全文索引。如果非要把非聚集索引类比成现实生活中的东西，那么非聚集索引就像新华字典的偏旁字典，他结构顺序与实际存放顺序不一定一致。 总结 使用聚集索引的查询效率要比非聚集索引的效率要高，但是如果需要频繁去改变聚集索引的值，写入性能并不高，因为需要移动对应数据的物理位置。 非聚集索引在查询的时候可以的话就避免二次查询，这样性能会大幅提升。 不是所有的表都适合建立索引，只有数据量大表才适合建立索引，且建立在选择性高的列上面性能会更好。 来源： https://my.oschina.net/u/4177395/blog/3100122

一.索引简介 众所周知，索引是关系型数据库中给数据库表中一列或多列的值排序后的存储结构，SQL的主流索引结构有B+树以及Hash结构，聚集索引以及非聚集索引用的是B+树索引。这篇文章会总结SQL Server以及MySQL的InnoDB和MyISAM两种SQL的索引。 SQL Sever索引类型有：唯一索引，主键索引，聚集索引，非聚集索引。 MySQL 索引类型有：唯一索引，主键（聚集）索引，非聚集索引，全文索引。 二.聚集索引 聚集（clustered）索引，也叫聚簇索引。 定义：数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引。 单单从定义来看是不是显得有点抽象，打个比方，一个表就像是我们以前用的新华字典，聚集索引就像是拼音目录，而每个字存放的页码就是我们的数据物理地址，我们如果要查询一个“哇”字，我们只需要查询“哇”字对应在新华字典拼音目录对应的页码，就可以查询到对应的“哇”字所在的位置，而拼音目录对应的A-Z的字顺序，和新华字典实际存储的字的顺序A-Z也是一样的，如果我们中文新出了一个字，拼音开头第一个是B，那么他插入的时候也要按照拼音目录顺序插入到A字的后面，现在用一个简单的示意图来大概说明一下在数据库中的样子： 地址 id username score 0x01 1 小明 90 0x02 2 小红 80 0x03 3 小华 92

序言 本篇主要目的有二： 1、看懂t-sql的执行计划，明白执行计划中的一些常识。 2、能够分析执行计划，找到优化sql性能的思路或方案。 如果你对sql查询优化的理解或常识不是很深入，那么推荐几骗博文给你： SqlServer性能检测和优化工具使用详细 ， sql语句的优化分析 ， T-sql语句查询执行顺序 。 执行计划简介 1、什么是执行计划？ 大哥提交的sql语句，数据库查询优化器，经过分析生成多个数据库可以识别的高效执行查询方式。然后优化器会在众多执行计划中找出一个资源使用最少，而不是最快的执行方案，给你展示出来，可以是xml格式，文本格式，也可以是图形化的执行方案。 2、预估执行计划，实际执行计划 选择语句，点击上面其中一个执行计划，预估执行计划可以立即显示，而实际执行计划则需要执行sql语句后出现。预估执行计划不等于实际执行计划，但是绝大多数情况下实际的执行计划跟预估执行计划都是一致的。统计信息变更或者执行计划重编译等情况下，会造成不同。 3、为什么要读懂执行计划 首先执行计划让你知道你复杂的sql到底是怎么执行的，有没有按照你想的方案执行，有没有按照最高效的方式执行，使用啦众多索引的哪一个，怎么排序，怎么合并数据的，有没有造成不必要资源浪费等等。官方数据显示，执行t-sql存在问题，80%都可以在执行计划中找到答案。 4、针对图形化执行计划分析 执行计划，可以以文本

转自： https://www.cnblogs.com/AK2012/archive/2013/01/04/2844283.html 　　SQL索引在数据库优化中占有一个非常大的比例， 一个好的索引的设计，可以让你的效率提高几十甚至几百倍，在这里将带你一步步揭开他的神秘面纱。 　　1.1 什么是索引？ 　　SQL索引有两种，聚集索引和非聚集索引，索引主要目的是提高了SQL Server系统的性能，加快数据的查询速度与减少系统的响应时间 下面举两个简单的例子： 图书馆的例子：一个图书馆那么多书，怎么管理呢？建立一个字母开头的目录，例如：a开头的书，在第一排，b开头的在第二排，这样在找什么书就好说了，这个就是一个聚集索引，可是很多人借书找某某作者的，不知道书名怎么办？图书管理员在写一个目录，某某作者的书分别在第几排，第几排，这就是一个非聚集索引 字典的例子：字典前面的目录，可以按照拼音和部首去查询，我们想查询一个字，只需要根据拼音或者部首去查询，就可以快速的定位到这个汉字了，这个就是索引的好处，拼音查询法就是聚集索引，部首查询就是一个非聚集索引. 看了上面的例子，下面的一句话大家就很容易理解了：聚集索引存储记录是物理上连续存在，而非聚集索引是逻辑上的连续，物理存储并不连续。就像字段，聚集索引是连续的，a后面肯定是b，非聚集索引就不连续了，就像图书馆的某个作者的书

摘自MSDN：“ CREATE INDEX (Transact-SQL) ” 为指定表或视图创建关系索引，或为指定表创建 XML 索引。可在向表中填入数据前创建索引。可通过指定限定的数据库名称，为另一个数据库中的表或视图创建索引。 create index indexName on tableName(colName) with (options) 这样创建的为 non unique ,nonclustered 索引 UNIQUE ：为表或视图创建唯一索引。 唯一索引不允许两行具有相同的索引键值 。视图的聚集索引必须唯一。 默认为non unique CLUSTERED：创建索引时，键值的逻辑顺序决定表中对应行的物理顺序。聚集索引的底层（或称叶级别）包含该表的实际数据行。 一个表或视图只允许同时有一个聚集索引 。有关详细信息，请参阅聚集索引结构。 如果没有指定 CLUSTERED，则创建非聚集索引。 NONCLUSTERED ：创建一个指定表的逻辑排序的索引。 对于非聚集索引，数据行的物理排序独立于索引排序。 有关详细信息，请参阅非聚集索引结构。 无论是使用 PRIMARY KEY 和 UNIQUE 约束隐式创建索引，还是使用 CREATE INDEX 显式创建索引。 每个表都最多可包含 249 个非聚集索引 。 对于索引视图，只能为已定义唯一聚集索引的视图创建非聚集索引。

作为一名开发人员，在日常的工作中会难以避免地接触到数据库，无论是基于文件的 sqlite 还是工程上使用非常广泛的 MySQL、PostgreSQL，但是一直以来也没有对数据库有一个非常清晰并且成体系的认知，所以最近两个月的时间看了几本数据库相关的书籍并且阅读了 MySQL 的官方文档，希望对各位了解数据库的、不了解数据库的有所帮助。  添加描述 本文中对于数据库的介绍以及研究都是在 MySQL 上进行的，如果涉及到了其他数据库的内容或者实现会在文中单独指出。 数据库的定义 很多开发者在最开始时其实都对数据库有一个比较模糊的认识，觉得数据库就是一堆数据的集合，但是实际却比这复杂的多，数据库领域中有两个词非常容易混淆，也就是数据库和实例： 数据库：物理操作文件系统或其他形式文件类型的集合； 实例：MySQL 数据库由后台线程以及一个共享内存区组成； 对于数据库和实例的定义都来自于 MySQL 技术内幕：InnoDB 存储引擎 一书，想要了解 InnoDB 存储引擎的读者可以阅读这本书籍。 数据库和实例 在 MySQL 中，实例和数据库往往都是一一对应的，而我们也无法直接操作数据库