生成索引，建立二叉查找树进行二分查找
生成索引，建立B-Tree结构进行查找
生成索引，按照B+-Tree结构进行查找 Mysql索引
生成索引，按照Hash结构进行查找
普通的二叉查找树会被深度限制搜索速度，深度增加1，就多进行一次IO。
B+Tree，Hash，BitMap
MySQL不支持BitMap，且支持InnoDB和MYISAM的
MySQL不显式支持Hash
? a： Ki 为关键字，关键字按升序排列，Ki<K（i-1）
? b: 关键字个数n，：ceil<=n<=m-1
? c: 非叶子节点的指针：p[1],p[2],….p[m],其中p[1]指向关键字小于K[1]的子树，p[m]指向关键字大于K[m-1]的子树，其他p[i],指向关键字属于（K[i-1],K[i]）的子树
缺点
都是根据哈希函数运算后的值，和原来的排序不一定对应
仅能满足 = IN，不能使用范围查询
无法用来被避免数据的排序操作
不能利用部分索引键查询
不能避免表扫描
遇到大量哈希值相等的情况，效率不一定比B+Tree高，哈希碰撞问题
BitMap索引 位图索引 未普及
?
疏松索引中的每个搜索码值都对应一个索引值
疏松索引文件只为索引码的某些值建立索引项
聚簇索引更快
? 原因：主键索引的叶子节点直接就是我们要查询的正航数据了。而非主键索引的节点是主键的值，查到主键的值之后，还需要再通过主键的值进行回表查询
不一定，原因：
? 覆盖索引（covering index）指一个查询语句的执行只需要从索引中就能取得，不必从数据表中读取。也可以称之为索引覆盖。
? 当一条查询语句符合覆盖索引条件时，Mysql只需要通过索引就可以返回查询所需的数据，这样避免了查到索引后再回表操作，减少I/O提高效率，
? 如：covering_index_sample中有一个普通索引：idx_key1_key2(key1,key2)。当我们通过SQL语句select key2 from covering_index_sample where key1=”keyset” 的时候，就可以通过覆盖索引查询，无需回表
? 覆盖索引是select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖。索引的字段不只包含查询列，还包含查询条件、排序等。
? 对查询频率较高，经常作为where条件的字段设置索引
?
通俗理解：
利用索引中的附加列，您可以缩小搜索的范围，但使用一个具有两列的索引 不同于使用两个单独的索引。复合索引的结构与电话簿类似，人名由姓和名构成，电话簿首先按姓氏对进行排序，然后按名字对有相同姓氏的人进行排序。如果您知道姓，电话簿将非常有用；如果您知道姓和名，电话簿则更为有用，但如果您只知道名不姓，电话簿将没有用处。
所以说创建复合索引时，应该仔细考虑列的顺序。对索引中的所有列执行搜索或仅对前几列执行搜索时，复合索引非常有用；仅对后面的任意列执行搜索时，复合索引则没有用处。
重点：
? 多个单列索引在多条件查询时优化器会选择最优索引策略，可能只用一个索引，也可能将多个索引全用上！ 但多个单列索引底层会建立多个B+索引树，比较占用空间，也会浪费一定搜索效率，故如果只有多条件联合查询时最好建联合索引！
? MySQL创建复合索引的规则是首先对符合索引的最左边的，也就是第一个索引字段上的数据进行排序，在第一个字段排序的基础上再对后面第二个索引字段进行排序，相当于实现了类似，order by 字段1，order by 字段2这样一种排序规则，所以第一个字段是绝对有序的，而第二个字段是无序的，因此直接对第二个字段进行条件判断是用不到索引的
顾名思义是最左优先，以最左边的为起点任何连续的索引都能匹配上，
注：如果第一个字段是范围查询需要单独建一个索引
注：在创建联合索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。因为Mysql索引查询会遵循最左优先原则，即最左优先，在检索数据时从联合索引的最左边开始匹配
? （这样的话扩展性较好，比如 userid 经常需要作为查询条件，而 mobile 不常常 用，则需要把 userid 放在联合索引的第一位置，即最左边）
?
联合索引本质：
当创建(a,b,c)联合索引时，相当于创建了(a)单列索引，(a,b)联合索引以及(a,b,c)联合索引
想要索引生效的话,只能使用 a和a,b和a,b,c三种组合；当然，我们上面测试过，a,c组合也可以，但实际上只用到了a的索引，c并没有用到！
同时存在联合索引和单列索引（字段有重复的），这个时候查询mysql会怎么用索引呢？
这个涉及到mysql本身的查询优化器策略了，当一个表有多条索引可走时, Mysql 根据查询语句的成本来选择走哪条索引；
有人说where查询是按照从左到右的顺序，所以筛选力度大的条件尽量放前面。网上百度过，很多都是这种说法，但是据我研究，mysql执行优化器会对其进行优化，当不考虑索引时，where条件顺序对效率没有影响，真正有影响的是是否用到了索引！
其他知识点：
1、需要加索引的字段，要在where条件中
2、数据量少的字段不需要加索引；因为建索引有一定开销，如果数据量小则没必要建索引（速度反而慢）
3、如果where条件中是OR关系，加索引不起作用
4、联合索引比对每个列分别建索引更有优势，因为索引建立得越多就越占磁盘空间，在更新数据的时候速度会更慢。另外建立多列索引时，顺序也是需要注意的，应该将严格的索引放在前面，这样筛选的力度会更大，效率更高。
? Index Condition Pushdown（索引下推） MySQL 5.6引入了索引下推优化，默认开启，使用SET optimizer_switch = ‘index_condition_pushdown=off’;可以将其关闭。官方文档中给的例子和解释如下： people表中（zipcode，lastname，firstname）构成一个索引
? SELECT * FROM people WHERE zipcode=‘95054’ AND lastname LIKE ‘%etrunia%’ AND address LIKE ‘%Main Street%’;
? 如果没有使用索引下推技术，则MySQL会通过zipcode=‘95054’从存储引擎中查询对应的数据，返回到MySQL服务端，然后MySQL服务端基于lastname LIKE ‘%etrunia%‘和address LIKE ‘%Main Street%‘来判断数据是否符合条件。 如果使用了索引下推技术，则MYSQL首先会返回符合zipcode=‘95054’的索引，然后根据lastname LIKE ‘%etrunia%‘和address LIKE ‘%Main Street%‘来判断索引是否符合条件。如果符合条件，则根据该索引来定位对应的数据，如果不符合，则直接reject掉。 有了索引下推优化，可以在有like条件查询的情况下，减少回表次数。
sql调优：
如何定位并优化慢查询sql
? 1.根据慢日志定位慢查询sql
? 2.使用explain等工具分析sql
? 3.修改sql或者让sql尽量走索引
explain关键字段
? type：
? index>all（都走全表扫描）
? extra：
? Using filesort 表示，Mysql会对结果按照外部索引次序排序，而不是从表里按照索引次序读到相关的内容，可能在内存或者磁盘上进行排序。MySQL中无法用索引完成的排序操作叫做“文件排序”
? Using temporary ：表示MySQL在对查询结果排序时使用的时临时表。常见于排序order by和分组查询group by
? 查询优化器：一条SQL语句的查询，可以有不同的执行方案，最终选择哪种方案，时通过查询优化器来选择的，，选择成本最低的方案，在一条语句真正的执行之前，MySQL的查询优化器会找出执行该语句所有可能使用的方案，对比之后找出成本最低的方案。这个成本最低的方案就是所谓的执行计划。
? 优化过程如下：1.根据搜索条件，找出所有可能使用的索引2.计算全表扫描的代价3.计算使用不同索引执行查询的代价4.对比各种执行方案的代价，找出成本最低的。
? 可以利用force index（）强制执行index
MySQL的查询优化器的最重要的目标是尽可能的使用索引，并且使用最严格的索引，来消除尽可能多的数据行，最终目标是提交select语句来查找数据行，而不是排除数据行。
? 优化器排除数据行的原因在于，他排除数据行的速度越快，找到与条件匹配的数据行也就越快
没选择主键索引的大致原因，应该是由于密集索引的叶子节点，把其他列的数据，也存放到了叶子节点当中
索引是建立的越多越好吗？
? 数据量小的表不需要建立索引，创建索引会增加额外的开销
? 数据变更需要维护索引，因此更多的索引意味着更高的维护成本
? 更多的索引也意味着需要更多的空间
原文：https://www.cnblogs.com/fanzihao/p/11342258.html