是时刻审核一下经常使用索引的姿态能否正确了！

索引，可以有效提高我们的数据库搜查效率，各种数据库优化八股文里都无关系的常识点可背，不过单纯的被条目其实很容易遗记。

所以松哥想经过几篇文章，和大家细心聊一聊索引的正确经常使用姿态，联合一些详细的例子来协助大家了解索引优化，这是一个小小的系列，或许会有几篇文章，当天先来第一篇。

1. 索引列独立

当我们将带有索引的列作为搜查的条件的时刻，须要确保索引不在表白式中，索引中也不蕴含各种运算。

我举个便捷例子，假定我有如下一张表：

一个 user 表，里边就四个字段，每个字段上都建了索引，如今有三条测试数据：

我们来比拟如下两个查问：

可以看到：

从上方的剖析中可以看到，只管 age-1=98 与 age=99 只管在逻辑上并无二致，然而 MySQL却无法智能解析第一个表白式，进而造成第一个无法经常使用索引。所以，我们不要在 where条件中写表白式，不只仅是上方这种表白式，一些经常使用了自带函数的表白式也不能经常使用，我们要尽量简化 where 条件。

不过上方这个例子太牵强了，普通大家不会犯这种失误，然而上方这个例子就不肯定了，或许会有小同伴在上方栽跟头：查问最近一年出世的用户(birthday列也是索引)：

在这张图里，我给出了两种不同的查问思绪：

依据上图 explain的结果，很显著第一种打算没有用上索引，启动了全表扫描;而第二种打算则用上了索引，只读取了两行数据就可以了。究其要素，就是由于第一种打算在索引列上启动了函数运算，造成MySQL 没法经常使用索引了。

2. 巧用笼罩索引

普通来说我们不倡导在查问中间接经常使用 select *，经常使用 select * 有很多疑问，其中一个疑问就是无法应用索引笼罩扫描(笼罩索引)。

那这里须要大家首先明确什么是笼罩索引。

在什么是 MySQL 的“回表”?一文中，松哥和大家聊了，索引依照物理存储方式可以分为聚簇索引和非聚簇索引。

我们日常所说的主键索引，其实就是聚簇索引(ClusteredIndex);主键索引之外，其余的都称之为非主键索引，非主键索引也被称为二级索引(Secondary Index)，或许叫作辅佐索引。

关于主键索引和非主键索引，经常使用的数据结构都是 B+Tree，惟一的区别在于叶子结点中存储的内容不同：

主键索引的叶子结点存储的是一行完整的数据。

非主键索引的叶子结点存储的则是主键值以及索引列的值。

这是两者最大的区别。

所以，搜查时假设经常使用了非主键索引，那么一共会搜查两棵 B+Tree，第一次性搜查 B+Tree 拿到主键值后再去搜查主键索引的B+Tree，这个环节就是所谓的回表。然而，假设搜查的字段刚好就在二级索引的叶子结点上，那么是不是就不须要回表了?我们来验证下。

假定我有如下一张表：

`id``username``address``gender`

id 是主键，username 和 address 是复合索引。

这表有三条记载：

我们来做个便捷测试，先来看如下 SQL：

这个查问 SQL，我们查问的字段是 username 和 address，由于这两个字段是复合索引，因此都保留在二级索引的 B+Tree的叶子结点中，搜查到 username 后也就能拿到 address 的值了，因此不须要回表查问。大家留意最后 Extra 中的 Using index就是这意思。

Using index 示意经常使用索引笼罩扫描来前往记载，间接从索引中过滤不须要的记载并前往命中结果，这是在 MySQL主机层成功的，然而毋庸再回表查问记载。

相反的情理，id 的值也存在于二级索引中，按理说也不须要回表，所以我稍微修正一下查问 SQL，添加 id，大家来看下：

可以看到跟我们想的一样。

那么我再加上 gender 呢?假设要查问的字段中蕴含 gender，由于 gender并没有保留在二级索引的的叶子结点中，那么此时就须要回表查问了：

可以看到，此时 Extra 为空，同时用到了二级索引 username，那么此时就须要回表了。

这个就是笼罩索引，巧用笼罩索引，能防止回表，提高查问效率。那么此时就要尽量防止经常使用 select *了(由于普通来说不太或许给一切字段都建设一个复合索引)。

好啦，不知道小同伴看明确没有，下篇文章我们继续~