背景

成本最低的优化手段，面试常问的面试题。
下面主要是讲InnoDB存储引擎的索引，InnoDB也是实际项目用的最多的存储引擎。

优势

提高数据查询效率。

缺点

占用空间、降低了增、删、改速度，因为要维护索引

原理

底层是B+树数据结构。

为什么采用树？

树形结构相对于线性结构可以提高查询效率。看下图：
线性表搜索数据只能遍历，搜索时间复杂度O(n)。平衡二叉树的搜索时间复杂度为O(logn)，等于树高。当n越大的时候，效率差距越大。

为什么不用Hash查询，时间复制度为O(1)?

因为不止有精确查询，还有范围查询，模糊查询。

为什么采用B+树？

下面看一下二叉树、平衡二叉树、B树、B+树的比较：

• 二叉树
  效率最差的时候会退化成列表。
• 平衡二叉树
  左右子树高度差不超过1，相同层级能存储更多数据。
• B树
  多叉平衡树，因为二叉树每个节点只能有两个子节点，所以当数据量大的时候，层级太深，搜索效率变低。B树每个节点可以有多个子节点，相同数据，层级更少，效率更高。（为什么层级越少效率越高？层级越低每层数据越多一次IO读取出来的数据越多，可以减少IO次数）
• B+树
  相比于B树来说，非叶子节点不存储数据，这样的好处是非叶子节点能存储更多的索引，可以进一步缩小层级，减少IO次数，提高效率。
  所有的查询都要查找到叶子节点，查询性能更稳定。
  所有的叶子节点形成一个有序列表，便于范围查询。
  
  
  
  

具体优化措施

需要建立索引的场景

• 主键自动建立唯一索引
• 频繁作为查询条件的字段应该创建索引(where后面的语句)
• 查询中与其它表关联的字段，外键关系建立索引
• 多字段查询下倾向创建组合索引
• 查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
• 查询中统计或者分组字段

不推荐建立索引的场景

• 表记录太少
• 经常增删改的表
• where条件里用不到的字段
• 字段值差异性太小的，比如性别

索引分类

• 主键索引
• 唯一索引
• 单值索引
• 复合索引

性能分析

SQL中对大量数据进行比较，关联，排序，分组时CPU的瓶颈。
​ 实例内存满足不了缓存数据或排序等需要,导致产生大量的物理IO。查询数据时扫描过多数据，导致查询效率低。

sql优化（待完善）

Explain

sql优化的绝招。
​ 使用EXPLAIN关键字可以模拟优化器执行SQL查询语句,从而知道MYSQL是如何处理SQL语句的,可以用来分析查询语句或是表的结构的性能瓶颈。
其作用:
表的读取顺序
哪些索引能够使用
数据读取操作的操作类型
那些索引被实际使用
表之间的引用
每张表有多少行被优化器查询

最左匹配原则

顾名思义：最左优先，以最左边的为起点任何连续的索引都能匹配上。同时遇到范围查询(>、<、between、like)就会停止匹配。
例如：b = 2 如果建立(a,b)顺序的索引，是匹配不到(a,b)索引的；但是如果查询条件是a = 1 and b = 2或者a=1(又或者是b = 2 and b = 1)就可以，因为优化器会自动调整a,b的顺序。再比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，因为c字段是一个范围查询，它之后的字段会停止匹配。

为什么有这个原则？
最左匹配原则都是针对联合索引来说的，所以我们有必要了解一下联合索引的原理。了解了联合索引，那么为什么会有最左匹配原则这种说法也就理解了。

我们都知道索引的底层是一颗B+树，那么联合索引当然还是一颗B+树，只不过联合索引的健值数量不是一个，而是多个。构建一颗B+树只能根据一个值来构建，因此数据库依据联合索引最左的字段来构建B+树。
例子：假如创建一个（a,b)的联合索引，那么它的索引树是这样的

可以看到a的值是有顺序的，1，1，2，2，3，3，而b的值是没有顺序的1，2，1，4，1，2。所以b = 2这种查询条件没有办法利用索引，因为联合索引首先是按a排序的，b是无序的。

同时我们还可以发现在a值相等的情况下，b值又是按顺序排列的，但是这种顺序是相对的。所以最左匹配原则遇上范围查询就会停止，剩下的字段都无法使用索引。例如a = 1 and b = 2 a,b字段都可以使用索引，因为在a值确定的情况下b是相对有序的，而a>1and b=2，a字段可以匹配上索引，但b值不可以，因为a的值是一个范围，在这个范围中b是无序的。

避免回表

回表是通过非主键索引查询到了主键，但是还要返回索引上面没有的属性，所以需要回到主键索引找到具体的数据行。因为非主键索引叶子节点只存储主键索引值，不存储具体数据