索引通常作为文件存储在磁盘上。(它也可以保存在内存中。)存储索引的原则可以粗略地概括为用空间交换时间。当数据库不添加索引时，默认情况下执行全局扫描。您需要多少次查询多少条数据，然后找到匹配的数据并将其放入结果集中，直到扫描整个表。在索引之后，KEY值被放置在n叉树上（B+Tree）。因为B+Tree该特性适用于在磁盘等直接存储设备上组织动态查找表。每次按索引执行条件查询时，都会根据key直接搜索值。

图片下载地址： MySQL标引原理-B+树的详细插图-MySQL文档类资源-CSDN下载

如上所示，它是一个B+Tree。浅蓝色块称为磁盘块，您可以看到每个磁盘块包含几个数据项。(以深蓝色显示)和指针(黄色所示)，例如磁盘块。1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17在磁盘块中，P2表示在17和35之间在磁盘块中，P3表示大于35磁盘块的数量。真实数据存在于叶节点，即。3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶节点不存储真实数据，只存储引导搜索方向的数据项，如17、35实际上并不存在于数据表中。

查找流程：如上图所示，如果您想要查找数据项29，则将首先放置磁盘块。1通过磁盘加载到内存，这种情况只发生一次。IO，使用内存中的二进制查找来确定29在17和35之间，锁定磁盘块。。1的P2指针、内存时间，因为它非常短(与磁盘相比。IO)可以忽略不计。1的P2指针的磁盘地址将磁盘块3通过磁盘加载到内存中，第二次出现IO，29在26和30之间，锁定磁盘块。。3的P2指针，通过指针加载磁盘块8记忆中，第三次发生IO同时，在内存中进行二进制搜索以找到它。29，结束查询，总共三次IO。事实是，3层的b+树可以代表数百万个数据。如果数百万个数据仅被搜索三次IO，性能提升将是巨大的，如果没有索引，每个数据项都会出现一次。IO，那么总共需要一百万次。IO显然，成本非常非常高。

B+Tree相对于B-Tree有几点不同：
非叶节点仅存储关键字值信息。
在所有叶节点之间有一个链指针。
数据记录存储在叶节点中。

为什么说B+Tree比B-Tree更适合实际应用的操作系统文件索引和数据库索引？
1、B+Tree磁盘读写成本更低。
B+Tree的内部节点没有指向关键字特定信息的指针。因此，它的内部节点相对B这棵树更小。如果同一内部节点的所有关键字都存储在同一磁盘块中，则该磁盘块可以容纳的关键字越多。你需要一次在内存中找到的关键词就越多。相对的IO读写次数减少。
2、B+Tree查询效率更加稳定。
由于非端点不是最终指向文件内容的节点，因此它只是叶节点中关键字的索引。因此，搜索任何关键字都必须遵循从根节点到叶节点的路径。所有关键字查询具有相同的路径长度，从而使每个数据的查询效率相当。
所以MyISAM，InnoDB引擎使用B+Tree作为索引结构。

2.索引的优缺点：

1、优点：

索引大大减少了服务器需要扫描的数据量，从而加快了数据检索速度，这也是创建索引的主要原因。
索引可帮助服务器避免排序和创建临时表。
索引可以是随机的。IO变成顺序IO(假设我们已经找到了第一条数据，并且其他所需的数据在这条数据之后，那么就不需要重新编排了，我们可以依次获得我们需要的数据。这被称为序列IO。）
索引对于InnoDB(对索引的行级锁的支持)很重要，因为它允许更少的查询锁的元组，并提高表访问的并发性。
通过创建唯一索引，可以保证数据库表中每行数据的唯一性。
可以加快表和表之间的连接，特别是在实现数据的引用完整性方面。
在使用GROUPING和SORTING子句进行数据检索时，还可以显著减少查询中的分组和排序时间。
通过使用索引，您可以在查询期间使用优化隐藏器来提高系统的性能。

2、缺点：

如果对表中的数据进行增、删、改，也需要动态维护索引，降低了表的更新速度。
索引需要占用物理空间。除了数据表，每个索引还会占用一定的物理空间。如果需要建立聚集索引，则需要的空间会更大。
如果一个数据列包含许多重复项，则对其进行索引不会有太大的实际效果。
对于非常小的表，在大多数情况下，简单的全表扫描效率更高。

索引只是提高效率的一个因素，如果您MySQL具有大量数据的表需要时间来研究和构建最佳索引或优化查询语句。因此，应该只对最频繁查询和最频繁排序的数据列进行索引。
MySQL同一数据表中的索引总数是有限的16个。

3.创建指数的原则和失败的原因：

1创建索引的原则：

主键自动建立唯一索引。
对查询条件使用频率较高的字段进行索引，选择区分程度较高的列作为索引。
单值/综合指数的选择更具成本效益。
在连接表时，最好对连接字段进行索引。
在频繁的排序或分组中(即， group by 或 order by 操作)，则适合进行索引。
经常使用distinct 应该对关键字查询的列进行索引。
筛选器返回的行数占整个表中总行数的百分比<=5%,应建立索引；如果返回的行数超过30%，即使有索引也是如此。MySQL它还将直接将执行计划更改为全表扫描，而不使用索引。

2在以下情况下不应使用索引：

对于更新量非常大的表，索引的维护成本会很高，如果它的检索要求很小，而且检索效率要求不是很高，就不适合创建索引，或者最小化索引。
由于表数据量较小，通过索引的减速速度不如全表扫描，不宜使用索引。
对于差异较小的列(例如“性别”)，如果通过索引的检索速度不如全表扫描的速度，则不应使用索引。
由于扫描范围占整个表的比例很大，通过索引检索的速度不如全表扫描，不宜使用索引。
不应定义类型BLOB/TEXT为大型字段(如)创建索引，否则会占用太多存储空间。

3索引失败的原因：

查询条件中最左侧的通配符。%开始，例如where a like %xx
查询条件使用IS NULL 或 IS NOT NULL
查询条件对字段进行数据或函数运算(包括隐式数据转换)
索引列不能参与计算并保持列“干净”
查询条件使用负查询条件：NOT,!=,<>,!<,!>,NOT IN, NOT LIKE 等。
即使相关字段建立了与第一个索引列不匹配的复合索引查询条件，即使覆盖了其他索引列，也无法使用该索引。因为综合索引是从左到右匹配的，即从第一个索引列到最后一个索引列。