索引：为什么要创建索引呢？这是因为，创建索引可以大大提高系统的性能。
第一，可以通过创建唯一索引来确保数据库表中每行数据的唯一性。 二是可以大大加快数据的检索速度。 这也是编制索引的最主要理由。 三是加快桌子和桌子之间的连接。 特别是在实现数据的参照完整性方面特别有意义。 第四，使用分组和排序子句搜索数据也可以大大减少查询中分组和排序所需的时间。 第五，通过索引，可以在查询过程中使用优化的隐藏器来提高系统性能。 既然添加索引有很多优点，为什么不为表中的每一列创建索引呢？ 这种想法有合理性，但也有片面性。 索引有很多优点，但向表中的每一列添加索引是不明智的。 这是因为增加索引也有很多不利的方面。
第一，索引的创建和维护需要时间。 该时间随数据量的增加而增加。 第二，索引需要物理空间。 除数据表外，每个索引还需要一定的物理空间。 创建集群索引时，所需的空间会变大。 第三，添加、删除和修改表中的数据时，索引也会动态维护，从而降低了数据维护速度。 索引是在数据库表的某些列之上创建的。 因此，在创建索引时，必须仔细考虑可以对哪些列进行索引。
可以对哪些列创建索引？ 通常，需要在列中创建索引，例如：
在需要频繁搜索的列中，可以加快搜索速度； 作为主键的列中，连接中常用的列主要具有外键，用于强制该列的唯一性和组织表中数据的数组结构，从而可以加速连接。 经常在需要根据范围搜索的列上创建索引。 因为索引已经排序，指定的范围是连续的。 在需要频繁排序的列上创建索引。 由于已经对索引进行了排序，因此查询可以利用索引排序来减少查询排序时间。 通过在WHERE子句中的列之上创建索引来加速条件的确定。 有些列不创建索引。 一般来说，这些不应该索引的列具有以下特征：
第一，不要在查询中很少使用或引用的列上创建索引。 这是原因
因此，这些列很少使用，因此有索引或没有索引无法提高查询的速度。 相反，由于索引增加，系统维护速度降低，空间要求增加。 第二，关于那个
不应该为具有较少数据值的列增加索引。 这是因为，像人力资源表中的性别列那样，这些列的可取值很少，在查询结果中，结果集中的数据行占表中数据行的很大比例
例如，需要在表中查找的数据行的百分比很大。 增加索引不会大幅提高搜索速度。 第三，不要向定义为text、image和bit数据类型的列添加索引。 这是因为这些列的数据量相当多或值很少。 第四，如果修改性能远大于检索性能，则不应该制作电缆
引用。 这是因为修正性能和检索性能矛盾。 增加索引会提高搜索性能，但会降低修改性能。 减少索引会提高修改性能，降低搜索性能。 因为
现在，如果修复性能远大于搜索性能，则不应该创建索引聚合索引。 通常，构建表时在表上添加主键。 在某些关系数据库中，如果在生成表时不指定主键，数据库将拒绝执行生成表的语句。 实际上，带有主键的表不能称为“表”。 在没有主键的表中，其数据无序地放置在磁盘存储器中，一行一行排列整齐，与我认知的“表”很接近。 如果给定了表的主键，则表在磁盘上的存储结构将从对齐结构转换为树结构，即上述“平衡树”结构。 换句话说，整个表都是索引。 是的。 我再说一遍。 整个表是一个索引，也就是所谓的“集合索引”。 所以，一个表只能有一个主键，一个表只能有一个“集合索引”。 主键的作用是将“表”的数据格式转换为“索引(平衡树)”的格式。
在这里写照片的说明
上图是具有主键的表(聚集索引)的结构图。 画不好，让我们看看。 其中，除树底部外的所有节点的数据都由主键字段中的数据组成。 这意味着通常指定主键的id字段。 最下面的部分是真正的表格数据。 假设要执行SQL语句。
select * from table where id=1256首先基于索引定位到具有值1256的叶节点，然后经由叶节点获得id为1256的数据行。 此处不详细介绍运行平衡树的细节，但如上图所示，树共有三层，从根节点到叶节点通过三次搜索即可获得结果。 如下图所示
在这里写照片的说明
如果一个表中有1亿个数据，则需要查找其中的一个数据，按照一般的逻辑需要一个一个地匹配。 最坏的情况是，为了得到结果需要一致1亿次。 在大的o标记法中是o(n )的最坏的时间复杂度，这是不能接受的。 而且，这1亿个数据显然不能一次读入存储器中供程序使用。 因此，在未进行缓存优化的情况下，这1亿次匹配是1亿次IO开销。 如果将此表转换为平衡树结构(非常茂盛且节点非常多的树)，假设此树有10层，则只需10次IO开销就可以找到所需的数据，速度将呈指数级提高。 在大的o表示法中，o(logn )，n记录总树，底数是树的分支数，结果是树的阶层数。 换言之，搜索次数是以树枝数为底记录总数的对数，用公式表示的是在这里写图像记述
用程序表示为math.log(1000000
00,10)，100000000是记录数，10是树的分叉数（真实环境下分叉数远不止10）， 结果就是查找次数，这里的结果从亿降到了个位数。因此，利用索引会使数据库查询有惊人的性能提升。然而， 事物都是有两面的， 索引能让数据库查询数据的速度上升， 而使写入数据的速度下降，原因很简单的， 因为平衡树这个结构必须一直维持在一个正确的状态， 增删改数据都会改变平衡树各节点中的索引数据内容，破坏树结构， 因此，在每次数据改变时， DBMS必须去重新梳理树（索引）的结构以确保它的正确，这会带来不小的性能开销，也就是为什么索引会给查询以外的操作带来副作用的原因。
非聚集索引讲完聚集索引 ， 接下来聊一下非聚集索引， 也就是我们平时经常提起和使用的常规索引。
非聚集索引和聚集索引一样， 同样是采用平衡树作为索引的数据结构。索引树结构中各节点的值来自于表中的索引字段， 假如给user表的name字段加上索引 ， 那么索引就是由name字段中的值构成，在数据改变时， DBMS需要一直维护索引结构的正确性。如果给表中多个字段加上索引 ， 那么就会出现多个独立的索引结构，每个索引（非聚集索引）互相之间不存在关联。 如下图
这里写图片描述
每次给字段建一个新索引， 字段中的数据就会被复制一份出来， 用于生成索引。 因此， 给表添加索引，会增加表的体积， 占用磁盘存储空间。
非聚集索引和聚集索引的区别在于， 通过聚集索引可以查到需要查找的数据， 而通过非聚集索引可以查到记录对应的主键值 ， 再使用主键的值通过聚集索引查找到需要的数据，如下图这里写图片描述
不管以任何方式查询表， 最终都会利用主键通过聚集索引来定位到数据， 聚集索引（主键）是通往真实数据所在的唯一路径。
覆盖索引（复合索引或者多字段索引查询）然而， 有一种例外可以不使用聚集索引就能查询出所需要的数据， 这种非主流的方法 称之为「覆盖索引」查询， 也就是平时所说的复合索引或者多字段索引查询。 文章上面的内容已经指出， 当为字段建立索引以后， 字段中的内容会被同步到索引之中， 如果为一个索引指定两个字段， 那么这个两个字段的内容都会被同步至索引之中。
先看下面这个SQL语句
//建立索引
create index index_birthday on user_info(birthday);//查询生日在1991年11月1日出生用户的用户名
select user_name from user_info where birthday = '1991-11-1'这句SQL语句的执行过程如下
首先，通过非聚集索引index_birthday查找birthday等于1991-11-1的所有记录的主键ID值
然后，通过得到的主键ID值执行聚集索引查找，找到主键ID值对就的真实数据（数据行）存储的位置
最后， 从得到的真实数据中取得user_name字段的值返回， 也就是取得最终的结果
我们把birthday字段上的索引改成双字段的覆盖索引
create index index_birthday_and_user_name on user_info(birthday, user_name);这句SQL语句的执行过程就会变为
通过非聚集索引index_birthday_and_user_name查找birthday等于1991-11-1的叶节点的内容，然而， 叶节点中除了有user_name表主键ID的值以外， user_name字段的值也结实的花卷， 因此不需要通过主键ID值的查找数据行的真实所在， 直接取得叶节点中user_name的值返回即可。 通过这种覆盖索引直接查找的方式， 可以省略不使用覆盖索引查找的后面两个步骤， 大大的提高了查询性能，如下图
这里写图片描述
数据库索引的大致工作原理就是像文中所述， 然而细节方面可能会略有偏差，这但并不会对概念阐述的结果产生影响 。