mysql性能优化：索引详解

索引的数据结构；b+tree，二叉树，红黑树，hash表最终选择b+tree

mysql索引数据结构是b+tree，mysql磁盘节点为16kb（默认）b+tree一个节点为16kb

         

 

b+tree图

b+tree查找：（每个节点上的元素都是顺序排列）把根节点放到内存然后折半查找目标元素，找到目标元素所在区间，然后根据该区间的磁盘文件地址找对对应节点，重复上述步骤，找对对应叶子节点，放内存中查找目标元素，取出数据，

myisam硬盘文件.frm（表结构文件）,myd（数据文件）,myi(索引文件)，

innodb硬盘文件；frm（表结构文件），ibd（数据和索引文件）

聚集索引（innodb的主键索引是聚集索引）；叶子节点包含了索引记录的全部数据（索引和数据放在一个文件）

非聚集索引；叶子节点包含索引记录的地址（索引和数据不放在一个文件里面）

innodb非主键索引采用非聚集索引叶子节点包含索引和索引所在行的主键，再通过主键索引查找记录

innodb建议建主键，推荐采用整型自增主键。

b+树会自动排序；

整型自增主键：查找的时候整型更快，整型占空间少，自增是因为在构建b+树时不用在排序了（排序插入时尾插法较快，在中间插入消耗性能大）。

非主键索引叶子节点存储主键值的原因：一致性和节省存储空间

mysql隐藏列用法（百度查找）

hash存储索引：对索引key进行一次hash计算就可以定位数据存储的位置；很多时候hash索引比b+树索引更高效（hash查找很快时间复杂度o（1））

但是不常用hash表存索引：仅能满足“=”、“in”，不支持范围查询（对用“>”这种范围性的查找hash索引做不到）；hash冲突问题

b+树索引支持范围查找，例如20

联合索引

联合索引：还是使用b+树，排序时先用第一个字段排序，第一个字段分不出来大小再按照第二个索引以此类推。

联合索引最左前缀原则！！！！！

覆盖索引原则

高选择性条件联合

创建复合索引的要素：最左前缀原则、覆盖索引原则、高选择性条件联合

ü适用于单独查询返回记录较多，而组合查询后返回记录较少的情况

例如where 学历= 研究生 以上会返回不少的记录，where 工作=厨师 同样会返回不少的记录

那么这2个条件任意一个查询做索引，都会不合适，但学历既是研究生且工作又是厨师的，返回的记录就少之又少了，

这时候创建复合索引就非常合适

组合查询的组合顺序，要考虑单独的前缀查询情况（否则单独前缀查询的索引不能生效或者只能用到跳跃索引），我们应该让选择性好的做为前导列

例如我们创建object_id,object_type的联合索引时，要看考虑是单独where object_id=xxx查询的多，还是单独

where object_type=xxx查询的多

仅等值无范围查询时，复合索引顺序不影响查询性能（比如where col1=xxx and col2=xxx，无论COL1+COL2组合还是COL2+COL1组合 都一样的效果）

复合索引最佳顺序一般是将列等值查询的列置前

能用覆盖索引的尽量用覆盖索引

 

 

mysql为什么选择为什么要选择b+树建索引而不是b_tree：二者区别，b+tree在叶子节点之间有一个双向指针；b-tree的非叶子节点不是冗余节点，是真正索引这样占空间较大，这样放入数据树的高度高；

索引规约

1.【强制】业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。

说明：不要以为唯一索引影响了insert速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。

2.【强制】超过三个表禁止join。需要join的字段，数据类型保持绝对一致；多表关联查询时，保证被关联的字段需要有索引。

说明：即使双表join也要注意表索引、SQL性能。

3.【强制】在varchar字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度。

说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为20的索引，区分度会高达90%以上，可以使用count(distinct left(列名,索引长度))/count()的区分度来确定。

4.【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。

说明：索引文件具有B-Tree的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。

5.【推荐】如果有order by的场景，请注意利用索引的有序性。order by最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现file_sort的情况，影响查询性能。

正例：where a=? and b=? order by c;索引：a_b_c

反例：索引如果存在范围查询，那么索引有序性无法利用，如：WHERE a>10 ORDERBY b;索引a_b无法排序。

6.【推荐】利用覆盖索引来进行查询操作，避免回表。

说明：如果一本书需要知道第11章是什么标题，会翻开第11章对应的那一页吗？目录浏览一下就好，这个目录就是起到覆盖索引的作用。

正例：能够建立索引的种类分为主键索引、唯一索引、普通索引三种，而覆盖索引只是一种查询的一种效果，用explain的结果，extra列会出现：using index。

7.【推荐】利用延迟关联或者子查询优化超多分页场景。

说明：MySQL并不是跳过offset行，而是取offset+N行，然后返回放弃前offset行，返回N行，那当offset特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行SQL改写。

正例：先快速定位需要获取的id段，然后再关联：SELECT a. FROM表1a, (select id from表1where条件LIMIT 100000,20 ) b where a.id=b.id

8.【推荐】SQL性能优化的目标：至少要达到range级别，要求是ref级别，如果可以是consts最好。

说明：1）consts单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。2）ref指的是使用普通的索引（normal index）。3）range对索引进行范围检索。

反例：explain表的结果，type=index，索引物理文件全扫描，速度非常慢，这个index级别比较range还低，与全表扫描是小巫见大巫。

9.【推荐】建组合索引的时候，区分度最高的在最左边。

正例：如果where a=? and b=?，a列的几乎接近于唯一值，那么只需要单建idx_a索引即可。

说明：存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置。如：where c>? and d=?那么即使c的区分度更高，也必须把d放在索引的最前列，即建立组合索引idx_d_c。

10.【推荐】防止因字段类型不同造成的隐式转换，导致索引失效。

11.【参考】创建索引时避免有如下极端误解：

1）索引宁滥勿缺。认为一个查询就需要建一个索引。2）吝啬索引的创建。认为索引会消耗空间、严重拖慢记录的更新以及行的新增速度。3）抵制惟一索引。认为惟一索引一律需要在应用层通过“先查后插”方式解决。