聚簇索引

通俗点讲 聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据 非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，myisam通过key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因 澄清一个概念：innodb中，在聚簇索引之上创建的索引称之为辅助索引，辅助索引访问数据总是需要二次查找，非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引，辅助索引叶子节点存储的不再是行的物理位置，而是主键值 何时使用聚簇索引与非聚簇索引 cluster.png 聚簇索引具有唯一性 由于聚簇索引是将数据跟索引结构放到一块，因此一个表仅有一个聚簇索引 一个误区：把主键自动设为聚簇索引 聚簇索引默认是主键 ，如果表中没有定义主键，InnoDB 会选择一个 唯一的非空索引 代替。如果没有这样的索引，InnoDB 会 隐式定义一个主键 来作为聚簇索引。InnoDB 只聚集在同一个页面中的记录。包含相邻健值的页面可能相距甚远。 如果你已经设置了主键为聚簇索引，必须先删除主键，然后添加我们想要的聚簇索引，最后恢复设置主键即可 。 此时其他索引只能被定义为非聚簇索引。这个是最大的误区。 刚才说到了，聚簇索引性能最好而且具有唯一性

索引是特殊的数据结构，它以易于遍历的形式存储部分集合数据集。索引存储特定字段或字段集的值，按字段值排序。 MongoDB的索引几乎与传统的关系型数据库索引一模一样，它的主键 _id 也是一个索引，MongoDB的数据按照 _id 的顺序存储在内存页与磁盘块上。但是， _id 与业务毫无关联，在业务相关的条件查询时，还是需要进行全表扫描才能找到对应页，效率并不高。 为了避免性能瓶颈，可以根据常用的查询建立索引 索引的值是按照一定的顺序排列的，使用索引键对文档进行排序效率非常高，只需要按照索引读取数据即可。 不过，使用索引也是有代价的，不仅会增加磁盘与内存的消耗，对于添加的每一个索引，每次写操作（插入、更新、删除）都会耗费更多时间，这是因为，数据发生变动时，还需要额外的开销更新索引。 文章目录 聚簇索引与非聚簇索引 MongoDB索引分类 主键索引 单字段索引 复合索引 复合索引与排序共用 唯一索引 复合唯一索引 去除重复 稀疏索引 TTL索引 全文索引 地理空间索引 索引优化 查询优化 写操作优化 聚簇索引与非聚簇索引 磁盘上的数据某一时刻只能有一种排序方式，而聚簇索引的特点是：索引顺序与数据存储顺序一致，所以聚簇索引只能有一个。 《数据库原理》中对聚簇索引的定义：聚簇索引的叶子节点是数据节点，非聚簇索引的叶子节点仍然是索引节点，只不过有指向对应数据块的指针。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 摘要 本篇介绍下Mysql的InnoDB索引相关知识，从各种树到索引原理到存储的细节。 InnoDB是Mysql的默认存储引擎(Mysql5.5.5之前是MyISAM， 文档 )。本着高效学习的目的，本篇以介绍InnoDB为主，少量涉及MyISAM作为对比。 这篇文章是我在学习过程中总结完成的，内容主要来自书本和博客(参考文献会给出)，过程中加入了一些自己的理解，描述不准确的地方烦请指出。 1 各种树形结构 本来不打算从二叉搜索树开始，因为网上已经有太多相关文章，但是考虑到清晰的图示对理解问题有很大帮助，也为了保证文章完整性，最后还是加上了这部分。 先看看几种树形结构： 1 搜索二叉树：每个节点有两个子节点，数据量的增大必然导致高度的快速增加，显然这个不适合作为大量数据存储的基础结构。 2 B树：一棵m阶B树是一棵平衡的m路搜索树。最重要的性质是每个非根节点所包含的关键字个数 j 满足：┌m/2┐ – 1 <= j <= m – 1；一个节点的子节点数量会比关键字个数多1，这样关键字就变成了子节点的分割标志。一般会在图示中把关键字画到子节点中间，非常形象，也容易和后面的 B+树区分。由于数据同时存在于叶子节点和非叶子结点中，无法简单完成按顺序遍历B树中的关键字，必须用中序遍历的方法。 3 B+树

目录 索引是什么？ 索引的作用 为什么索引的数据结构使用B+Tree？ 平衡二叉查找树 多路平衡查找树 B-Tree 多路平衡查找树加强版 B+Tree B+Tree与B-Tree的区别 MySQL中B+Tree的表现形式 MyISAM引擎 InnoDB引擎 覆盖索引 联合索引 最左前缀原则 索引是什么？ 索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。 索引的作用 索引能极大的减少存储引擎需要扫描的数据量。 索引可以把随机IO变成顺序IO。 索引可以帮助我们在进行分组、排序等操作时，避免使用临时表。 为什么索引的数据结构使用B+Tree？ 平衡二叉查找树 缺点： 太高：树的高（深）度决定着它的IO操作次数。显然，当数据量逐渐增加时，平衡二叉树的深度也会显著增加。 太小：每一个节点保存的数据量太小了。没有很好的利用操作磁盘IO的数据交换特性，也没有利用好磁盘IO的预读能力（空间局部性原理），从而带来频繁的IO操作。 多路平衡查找树 B-Tree 查询的效率取决于与磁盘IO的次数，减少磁盘IO的次数就必须要压缩树的高度，B-Tree 很好的解决了平衡二叉树的小与高的问题，让瘦高的树尽量变成矮胖的树。 多路平衡查找树加强版 B+Tree B+Tree与B-Tree的区别 B+Tree节点关键字搜索采用闭合区间。 B

一、InnoDB实现原理 虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同。因为InnoDB支持聚簇索引（主键索引），聚簇索引就是表，所以InnoDB不用像MyISAM那样需要独立的行存储。也就是说，InnoDB的数据文件本身就是索引文件。 聚簇索引的每一个叶子节点都包含了主键值、事务ID、用于事务和MVCC的回滚指针以及所有的剩余列。假设我们以col1为主键，则下图是一个InnoDB表的聚簇索引（主键索引）（Primary key）示意。 与MyISAM不同的是，InnoDB的二级索引和聚簇索引很不相同。InnoDB的二级索引的叶子节点存储的不是行号（行指针），而是主键列。这种策略的缺点是二级索引需要两次索引查找，第一次在二级索引中查找主键，第二次在聚簇索引中通过主键查找需要的数据行。 画外音：可以通过我们前面提到过的索引覆盖来避免回表查询，这样就只需要一次回表查询，对于InnoDB而言，就是只需要一次索引查找就可以查询到需要的数据记录，因为需要的数据记录已经被索引到二级索引中，直接就可以找到。 因为InnoDB的索引的方式通过主键聚集数据，严重依赖主键。索引如果没有定义主键，那么InnoDB会选择一个唯一的非空索引代替。如果没有这样的索引，InnoDB会隐式定义一个主键来作为聚簇索引。 二、优缺点 优点 可以把相关数据存储在一起

目录 1.什么是索引？为什么要用索引？ 1.1索引的含义 1.2为什么用？ 2.索引的作用与缺点 2.1作用 2.2缺点 3.索引的使用场景 3.1应创建索引的场景 3.2不应创建索引的场景 4.索引的分类与说明 4.1主键索引 4.2单列索引 4.3唯一索引 4.4复合索引 4.5聚集索引与非聚集索引 4.5.1聚集索引 4.5.2非聚集索引 4.5.3使用及语法 4.5.4使用场景对比 4.6聚簇索引与非聚簇索引 4.6.1聚簇索引 4.6.2非聚簇索引 4.6.3Mysql的MYISAM和INNODB引擎 4.6.4对比总结 4.7稠密索引与稀疏索引 4.7.1稠密索引 4.7.2稀疏索引 5.索引的底层原理 5.1 B-Tree 5.2 B+Tree 5.3 B-树和B+树的区别 6. 总结 1.什么是索引？为什么要用索引？ 1.1索引的含义 数据库索引,是数据库管理系统中一个排序的数据结构,以协助快速查询,更新数据库中表的数据.索引的实现通常使用B树和变种的B+树(mysql常用的索引就是B+树)。除了数据之外,数据库系统还维护为满足特定查找算法的数据结构,这些数据结构以某种方式引用数据.这种数据结构就是索引！ 简言之，索引就类似于书本，字典的目录！ 1.2为什么用？ 打个比方，如果正确合理设计并且使用索引的MySQL是一辆兰博基尼的话

作者：草木青川 链接：https://zhuanlan.zhihu.com/p/82871762 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 lc里最长上升子序列的变形题。实现输入英文单词联想的功能二面：矩阵旋转，要求空间复杂度O(1)无序的数组的中位数。要求时间复杂度尽可能的小计算机网络tcp 怎么保证数据包有序1. 主机每次发送数据时，TCP就给每个数据包分配一个序列号并且在一个特定的时间内等待接收主机对分配的这个序列号进行确认，2. 如果发送主机在一个特定时间内没有收到接收主机的确认，则发送主机会重传此数据包。3. 接收主机利用序列号对接收的数据进行确认，以便检测对方发送的数据是否有丢失或者乱序等，4. 接收主机一旦收到已经顺序化的数据，它就将这些数据按正确的顺序重组成数据流并传递到高层进行处理。tcp 和 udp 的异同TCP是面向流的可靠数据传输连接UDP是面向数据包的不可靠无连接tcp 怎么保证可靠性差错检验机制，反馈机制，重传机制，引入序号，滑动窗口协议，选择重传tcp 中 拥塞避免 和 流量控制 机制拥塞避免和流量控制这两种机制很像，但是流量控制是由接收方的接受能力也就是接收窗口所决定的，如果接收窗口够大，以动态调整发送窗口的大小调整发送速度拥塞避免主要由网络情况所限制，网络情况良好，则加大发送速率，网络状态差（冗余ACK和丢包

设计和调整索引 　　无法定义可在任何地方使用的索引策略。每个系统都是独一无二的，需要基于工作负载，业务需求和其他一些因素的自己的索引方法。但是，有几个设计考虑因素和指南可以应用于每个系统。 　　当我们优化现有系统时也是如此。虽然优化是一个在每种情况下都是独特的迭代过程，但是有一组技术可用于检测每个数据库系统中的低效率。 在本章中，我们将介绍在设计新索引和优化现有系统时需要记住的几个重要因素。 聚集索引设计注意事项 　　每次更改聚簇索引键的值时，都会发生两件事。首先， SQL Server 将行移动到聚簇索引页链和数据文件中的不同位置。其次，它更新了 row-id ，它是聚集索引键。存储了行 id ，需要在所有非聚簇索引中更新。就 I / O 而言，这可能是昂贵的，特别是在批量更新的情况下。此外，它可以增加聚簇索引的碎片，并且在行 ID 大小增加的情况下，可以增加非聚簇索引的碎片。因此，最好有一个静态聚簇索引，其中键值不会改变。 　　 所有非聚簇索引都使用聚簇索引键作为 row-id 。过宽的聚簇索引键会增加非聚簇索引行的大小，并且需要更多空间来存储它们。因此， SQL Server 需要在索引或范围扫描操作期间处理更多数据页，这会降低索引的效率。 　　 在非唯一非聚簇索引的情况下， row-id 也存储在非叶索引级别，这反过来会减少每页索引记录的数量，并可能导致索引中的额外中间级别

文章选自：《Pro SQL Server Internals, 2nd edition》CHAPTER 2 Tables and Indexes 作者：Dmitri Korotkevitch 第七章 设计和调整索引 It is impossible to define an indexing strategy that will work everywhere. Every system is unique and requires its own indexing approach based on workload, business requirements, and quite a few other factors. However, there are several design considerations and guidelines that can be applied in every system. 我们无法定义可在任何地方使用的索引策略。 每个系统都是独一无二的，需要基于工作负载，业务需求和其他一些因素定义自己的索引方法。但是，还是有几个设计考虑因素和指南可以应用于每个系统。 The same is true when we are optimizing existing systems. While optimization is an

在应用系统中，尤其在联机事物处理系统中，对数据查询及处理速度已成为衡量应用系统的标准。 而采用索引来加快数据处理速度也成为广大数据库用户所接受的优化方法。 在良好的数据库设计基础上，能够有效地索引是SQL Server取得高性能的基础,SQL Server采用基于代价的优化模型,他对每一个提交的有关表的查询，决定是否使用索引或用哪一个索引。因为查询执行的大部门开销是磁盘I/O，使用索引提高性能的一个主要目标就是避免全表扫描，因为全表扫描需要从磁盘上读表的每一个数据页，如果有索引指向数据值，则查询只需要读几次磁盘就能了。所以如果建立了合理的索引，优化器就能利用索引加速数据的查询过程。不过，索引并不总是提高系统的性能，在增、删、改操作中索引的存在会增加一定的工作量，因此，在适当的地方增加适当的索引并从不合理的地方删除次优的索引，将有助于优化那些性能较差的SQL Server应用。实践表明，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引和程式结合起来，才能产生最佳的优化方案。本文就是SQL Server索引的性能问题进行了一些分析和实践。 一、聚集索引(clustered indexes)的使用 聚集索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由于聚簇索引的索引页面指针指向数据页面，所以使用聚簇索引查找数据几乎总是比使用非聚簇索引快。