1.B+树索引

1.1不同应用中B+树索引的使用

OLTP:查询操作只从数据库中取得一小部分的数据，一般可能都在10条记录以下，或者1条记录
是建立B+树索引最有意义的，否则即使建立了，优化器可能选择不使用索引。

OLAP:需要访问表中大量的数据根据这些数据来产生查询结果，这些查询多是面向分析查询，并提供给决策者。对于OLAP复杂查询，要涉及多张表之间的连接，索引添加依然有意义。但是Hash JOIN 索引变得不重要了，在OLAP需要对时间字段进行索引

1.2联合索引

联合索引使用情况:
**联合索引键值>=2 **

数据按照(a,b)的顺序进行了存放如上图。
用SELECT * FROM TABLE WHERE a=xxxx and b=xxxx 可以使用(a,b)这个联合索引。
已经对第二个键值进行了排序处理
联合索引（a，b）其实根据列a,b进行排序下列语句可以直接使用联合索引得到:
select … from table where a=xxx order by b
然鹅对于(a,b,c)同样可以直接通过联合索引得到结果:
SELECT … FROM TABLE WHERE a=xxx ORDER BY b
SELECT … FROM TABLE WHERE a=xxx AND b=xxx ORDER BY c

1.3覆盖索引

InnoDB存储引擎支持覆盖索引(Covering index 索引覆盖) 从辅助索引中得到查询的记录，不需要查询聚集索引的记录。

好处：辅助索引不包含整行记录的所有信息，故其大小远小于聚集索引可以减少大量的IO操作
好处2：对于统计问题
SELECT COUNT(*) FROM TABLE
InnoDB引擎不会选择查询聚集索引进行统计而是选择辅助索引（数量小减少IO操作）

1.4优化器选择不使用索引的情况

当执行EXPLAIN命令进行SQL语句分析，优化器并没有选择索引去查找数据，而是通过聚集索引（扫描全表得到数据）发生于范围查找，JOIN链接操作等情况。
例子：
在这里插入图片描述

该表中(OrderID,ProductID)的联合主键，此处还有对于OrderID的单个索引。上述SQL本可以通过OrderID上索引进行数据查找。结果却是走的主键。
在这里插入图片描述

在possible_keys一列可以看到查询使用PRIMARY OrdersOrder_Details三个索引，在最后的索引使用中，优化器选择了PRIMARY聚集索引

原因：用户要选取的数据是整行信息，而OrderID索引不能覆盖我们要查询信息，因此在对OrderID索引查询到指定数据后，还需要一次书签访问查找整行数据信息。（OrderID索引中数据顺序存放再次进行书签查找的数据无序变成离散读操作若要求访问数据量很小则优化器会选择辅助索引但访问数据占整个表中数据的蛮大部分时优化器通过聚集索引找数据）
不能进行索引覆盖的情况，优化器选择辅助索引的情况是：通过辅助索引查找的数据量是少量的。
若使用固态硬盘，随机读操作非常快，确定辅助索引可以带来更好的性能，可以使用关键字FORCE INDEX来强制使用某个索引。
SELECT * FROM orderdetails FORCE INDEX(OrderID) WHERE orderid>10000 and orderid<10200