简介

这里主要介绍索引的功能，以及为什么，它可帮助使用者优化如何查询已经存储的数据的同时，过多的使用反而导致性能下降？

索引通过最大限度地减少完成查询所需的光盘访问次数来提高数据库性能。

它是一种数据结构技术，用于查找和快速访问数据库中的数据。多个数据库字段用于生成索引。表的主键或候选键在第一列中重复，即搜索键。

为了加快数据检索速度，这些值也按排序顺序保存。应该强调的是，不需要对数据进行排序。

第二列是数据引用或指针，其中包含一组指针，用于保存可以找到该特定键值的磁盘块的地址

索引和优化器提示 可单独使用或一起使用。

索引提示适用于 SELECT,DELETE 和 UPDATE 语句。 索引提示一般在表名之后指定。

1 数据库索引

MySQL和Oracle等数据库本身提供索引的功能，合理创建索引可以提高数据的检索效率，降低数据库服务器IO和CPU的消耗。

但由于索引也会降低更新表的速度，经常增删改的表或字段不适合创建索引，所以在开发初期，我们就应该根据数据库模型表和字段的作用来决定是否为该表建立索引，为数据记录较多的表中，频繁作为查询条件的字段建立索引。

            #python3
		class Article(models.Model):
			"文章"
			title = models.CharField('标题',max_length=200,)
			class Meta:
				indexes = [models.Index(fields=['title']),]

2 索引过多的问题

表所允许的索引数量，数据库允许的索引数量，最大并发事务处理能力，负载均衡能力，最大连接数。

索引太多的问题

对于太小的表，经常更新的的属性和表，属性值很少的查询，过长的属性，特殊数据类型的属性比如大文本，多媒体数据，不出现或很少出现的属性不宜建立索引。

而对于常用属性建立太多属性将会降低增删改查的性能。 也会导致数据库体积变大，加大数据库优化的开销，数据库将对索引定义建立列计算统计信息更新开销，过多的索引导致更新范围大，时间变长。
索引失效维护成本高。

• 索引过多

是指单表上非聚集索引数量太多，至于多少才为太多，这个实际上没有标准，虽然某些书上有说过单表上不要超过6个索引，但是那些书是 通常是很久远的书籍（大概10年前左右），那时候的硬件资源还没比较紧张，不可能支持太多索引。但是即使是今天的硬件资源，随着系统的复杂程度和数据量的 增长，硬件资源也容易不足，同时索引过多也会带来很多风险。 以下详细解读。

3 具体风险主要有以下几个：

• 降低增删改操作的性能。

由于增删改操作特别是删、增两个，往往引发聚集索引键的变更，标上的非聚集索引叶节点存储了聚集索引键，所以也会连带被更 新。而这些非聚集索引往往是没有提高这些操作的性能，反而对操作带来负面影响。这就是所谓的牵一发而动全身。

如果有些增删改操作带有WHERE条 件，这些情况下，有些索引能提高性能，比如百万级别的表中删除一行数据，如果没有索引（假设连聚集索引也没有），那么就只有扫描全表删除，那速度简直无法接受。

• 过多索引还导致了数据库“体积”变大。

本质上，数据库的性能问题几乎都是由于“体积”过大导致的。我们知道，聚集索引就是表本身，表多大，聚集索 引几乎就有多大，根据B-Tree的层级，可能会比表更大（不过一般大不了多少）。而非聚集索引叶子节点由于存储了索引键的数据，索引也有一定体量。

• 过多索引导致存储压力和维护开销。

由于SQL Server不直接访问磁盘，每个操作都需要先把数据从磁盘加载到内存中，内存的容量相对磁盘来说又比较小，一旦索引很大，查询过程造成的内存压力也会随 之而来，对数据缓存和计划缓存都有不可忽视的影响。对聚集索引的维护，比如重建，会引发非聚集索引的连带效应。索引越多速度越慢。很多系统并没有充足的时 间让你任意维护索引。

• 加大了SQL Server优化开销。

虽然通常优化引擎不会花太多时间在优化上，最起码相对于执行而言，优化的时间你可能感知不到，但是过度优化、编译重编译，都会对 CPU带来压力。

当索引很多时，优化器必须针对查询及上面的统计信息进行分析，如果有一些索引都能支持这个查询时，优化器又必须比对哪个索引开销更低。 要优化器选择也有选择恐惧症，太多的选择它就会折中，不一定会花更多资源去选择最优方案，万一当时其他操作的影响导致优化器选择了不合理的索引，性 能反而更差。

统计信息更新开销，默认情况下，SQL Server会对索引定义中的列计算统计信息，这种统计信息是索引级别的，每个索引有自己的统计信息，索引越多，由于数据变更或者其他变更带来统计信息更新时，需要更新的范围就越大，时间越久。

• 索引失效：
  这是我写这系列文章的原因，因为本人运维的数据库不定期出现某些功能卡的情况，通过重建索引，功能恢复一定时间的稳定，但是过一段时间 后又出现了。

从表象看来，这类似与索引失效的情况，但是目前官方资料中并没有出现索引失效的描述，所以可以认为索引失效其实只是个表象，更多的是优化器对 索引选择的混乱。

通过降低索引的数量和提高每个索引的重用度，这种情况目前再无发生。简单来说，对于OLTP数据库，单表索引不应该过多。

4 总结

一个简单的经验标准：

对于核心表：所有索引不要超过7个。
对于普通表：所有索引不要超过5个。
对于小型表：所有索引不要超过3个。

当单表有很多索引（比如上面提到的20多个）时，就应该考虑是否真有必要维持这种数量，在本系列的最后部分会给出解决方案。

当然极端情况下，20多个索引的表性能表现也不一定不好。当然，总是需要按照实际场景需求去分析的。