认识达内从这里开始

我们在上文中给大家简单介绍了，MySQL数据库索引的类型与应用等一些基础知识内容，而本文我们就继续来学习一下，数据库索引策略与优化方式分享。

1、索引策略

下面是关于建立索引的一些常见策略：

一是需要考虑的是预测那些数据为热点数据或者热点列，按照《高性能Mysql》介绍，对于热点列来说有时候要违背大选择性的原则，通过建立时常搜索的索引作为左前缀的默认的设置。同时优化查询需要考虑所有的列，如果一个查询的优化会破坏另一个查询，那么就需要优化索引的结构。

二是考虑where的条件组合，通过组合多种where条件，需要考虑的是尽可能让查询重用索引而不是大规模的建立新索引。

避免多个范围进行扫描，一方面是范围查询会导致，但是对于多个等值的条件查询，好的办法是尽量控制搜索范围。

对于索引的策略我们还需要了解下面的细节

单行访问很慢，特别是随机访问要比顺序访问要慢更多，一次性加载很多数据页会造成性能的浪费。

顺序访问范围数据很快，顺序IO的速度不需要多磁道查找，比随机的访问IO块很多，顺序访问也可以使用groupby进行聚合计算。

索引覆盖速度很快，如果查询字段包含了索引列，就不需要回表。

2、索引碎片优化

Innodb的数据结构和特性会导致索引存在数据碎片，对于任何存储结构来说顺序的存储结构是合适的，并且索引顺序访问要比随机访问快更多，数据存储的碎片比索引本身复杂很多，索引碎片通常包含下面的情况：

行碎片：数据行的数据被存储在多个数据页当中，碎片可能会导致性能的下降。

行间碎片：逻辑顺序上的页，行在磁盘上不顺序存储，行间数据碎片会导致全表扫描。

剩余空间碎片：数据页的间隙有大量的垃圾数据导致的浪费。

对于上面几点，对于myisam都有可能出现，但是innodb的行碎片不会出现，内部会移动碎片重写到一个片段。

索引碎片的处理方式：在Mysql中可以通过optimizetable导入和导出的方式重新整理数据，防止数据碎片问题。

3、索引规则

索引必须按照索引顺序从左到右匹配

如果在查询中间出现范围，则范围查询之后的索引失效

不能跳过索引列的方式查询(和B+tree索引数据结构设计有关系)

接着是索引顺序问题，由于BTree的结构特性，索引都是按照建立顺序进行查找的，通常不包含排序和分组的情况下，把选择性高的索引放在左列是一个普遍正确策略。

如何查看索引基数：showindexfromsakila.actor，还有一种方式是通过information_schema.statistics表查询这些信息，可以编写为一个查询给出选择性较低的索引。

当innodb打开某些表的时候会触发索引信息的统计，比如打开information_schema表或者使用showtablestatus和showindex的时候，所以如果在系统要运行压力较大的业务时期尽量避开这些操作。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。