索引总结

最新推荐文章于 2020-11-15 10:33:30 发布

百合静流-秋之回忆

最新推荐文章于 2020-11-15 10:33:30 发布

阅读量168

点赞数

文章标签：索引聚簇索引组合索引索引种类

本文链接：https://blog.csdn.net/iverson2010112228/article/details/82632008

版权

索引的分类

索引种类

https://segmentfault.com/a/1190000010991930

下面讲的是常用的BTree索引

主键索引

主键：一种唯一性索引，必须指定为primary key

唯一索引

普通索引

组合索引

多个单列索引与单个多列索引的查询效果不同，因为：

执行查询时，MySQL只能使用一个索引，会从多个索引中选择一个限制最为严格的索引。

全文索引

从3.23.23版开始支持全文索引和全文检索，FULLTEXT，

可以在char、varchar或text类型的列上创建。

索引结构

B-Tree索引

算法待研究TODO

InnoDB使用的是B+TREE，即每个叶子节点都包含指向下一个叶子节点的指针，从而方便叶子节点范围遍历。
不同存储引擎使用B-TREE索引的方式也不同。例如MyISAM使用前缀压缩技术使索引更小，而InnoDB则按照原数据格式进行存储。再如MyISAM索引通过数据的物理位置引用被索引的行，而InnoDB则根据主键引用被索引的行。
B-TREE中的所有值都是按顺序存储的，每个叶子页到根的距离相同。

聚簇索引和非聚簇索引

InnoDB 主键使用的是聚簇索引，MyISAM 不管是主键索引，还是二级索引使用的都是非聚簇索引。

单列索引和组合索引

选择性

如果我们的查询where条件只有一个，我们完全可以用单列索引，这样的查询速度较快，索引也比较瘦身。如果我们的业务场景是需要经常查询多个组合列，不要试图分别基于单个列建立多个单列索引（因为虽然有多个单列索引，但是MySQL只能用到其中的那个它认为似乎最有效率的单列索引）。这是因为当SQL语句所查询的列，全部都出现在复合索引中时，此时由于只需要查询索引块即可获得所有数据，当然比使用多个单列索引要快得多。

如果你有三个单列的索引，MySQL会试图选择一个限制最严格的索引。但是，即使是限制最严格的单列索引，它的限制能力也肯定远远低于firstname、lastname、age这三个列上的多列索引。

多列索引维护的成本要大一些，并且索引数据占用的存储空间也要更大一些

对于复合索引:Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。例如索引是key index (a,b,c). 可以支持a | a,b| a,b,c 3种组合进行查找，但不支持 b,c进行查找 .当最左侧字段是常量引用时，索引就十分有效。

将选择性最高的列放到索引的最前列虽然是一条重要的参考准则，但通常不如避免随机IO和排序那么重要。所以在设计索引时，还要考虑到WHERE子句中的排序、分组和范围条件等其他因素，这些因素可能对查询的性能造成非常大的影响。

索引合并

如果在EXPLAIN中看到有索引合并，那就应该好好检查一下查询和表的结构，看看是不是已经是最优的。

根据官方文档中的说明，我们可以了解到：
1、索引合并是把几个索引的范围扫描合并成一个索引。
2、索引合并的时候，会对索引进行并集，交集或者先交集再并集操作，以便合并成一个索引。
3、这些需要合并的索引只能是一个表的。不能对多表进行索引合并。

使用索引合并有啥收益
简单的说，索引合并，让一条sql可以使用多个索引。对这些索引取交集，并集，或者先取交集再取并集。从而减少从数据表中取数据的次数，提高查询效率。

怎么确定使用了索引合并
在使用explain对sql语句进行操作时，如果使用了索引合并，那么在输出内容的type列会显示 index_merge，key列会显示出所有使用的索引

在explain的extra字段中会以下几种：
Using union 索引取并集
Using sort_union 先对取出的数据按rowid排序，然后再取并集
Using intersect 索引取交集

mysql索引合并:一条sql可以使用多个索引

最佳实践

只有当索引的列顺序和ORDER BY子句的顺序完全一致，并且所有列的排序方向都一样时，才能使用索引对结果进行排序。一般情况ORDER BY子句和查找型查询的限制是一样的，都需要满足索引的最左前缀要求。但有一种特殊情况，如果在WHERE子句或JOIN子句中对索引前导列指定了常量，则order by子句可以不满足索引的最左前缀的要求。

注意项

mysq会统计每个索引上的重复度，选用低重复度的字段。另外一个age的索引就不会用到，但还有维护索引的开销，所以age的索引不需要创建。

B-Tree索引对如下类型的查找有效：
全值匹配：查找条件和索引中的所有列相匹配
匹配最左前缀：查找条件只有索引中的第一列
匹配列前缀：只匹配某一列值的开头部分。这里并不一定只能匹配第一个索引列的前缀。例如在确定第一个索引列的值时，也可以在第二个索引列上匹配列前缀。在上面例子中，对于查找姓为Allen，名为J开头的人，也可以应用到索引。
匹配范围值，或者精确匹配某一列并范围匹配另外一列：例如查找姓在Allen和Barrymore之间的人，或者查找姓为Allen，名字在某一个范围内的人。
只访问索引的查询，即要查询的值在索引中都包含，只需要访问索引就行了，无需访问数据行。这种索引被称作覆盖索引。
对于上面列出的查询类型，索引除了可以用来查询外，还可以用来排序。
下面是B-Tree索引的一些限制：

如果不是从索引的最左列开始查找，则无法使用索引。例如直接查找名字为Bill的人，或查找某个生日的人都无法应用到上面的索引，因为都跳过了索引的第一个列。此外查找姓以某个字母结尾的人，也无法使用到上面的索引。
不能在中间跳过索引中的某个列，例如不能查找姓为Smith，生日为某个特定日期的类。这样的查询只能使用到索引的第一列。
如果查询中有某个列的范围查询，则该列右边的所有列都无法使用索引优化查找。例如有查询WHERE last_name=‘Smith’ AND first_name LIKE ‘J%’ AND dob=‘1976-12-23’，这个查询只能使用到索引的前两列，而不能使用整个索引。
通过上面列出的这些条件，可见对于一个B-TREE联合索引，索引列的顺序非常重要。

索引优化

MySQL支持很多数据类型，选择合适的数据类型存储数据对性能有很大的影响。通常来说，可以遵循以下一些指导原则：

越小的数据类型通常更好：越小的数据类型通常在磁盘、内存和CPU缓存中都需要更少的空间，处理起来更快。
简单的数据类型更好：整型数据比起字符，处理开销更小，因为字符串的比较更复杂。在MySQL中，应该用内置的日期和时间数据类型，而不是用字符串来存储时间；以及用整型数据类型存储IP地址。
尽量避免NULL：应该指定列为NOT NULL，除非你想存储NULL。在MySQL中，含有空值的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值。

如果我们的锁用到索引就是行锁，如果没有用到索引就是表锁，但是我们操作的数据必须用到锁才行；