高并发之存储篇：关注下索引原理和优化吧！躲得过实践，躲不过面试官！( 三 )

本文插图
寻求改进：这样的方式所需大量连续空间 + 目录会随数据变动而频繁变动，怎么办？
5演进：主键B+树方式
其实，在叙述行记录结构的时候，我们就看到，数据行的结构中，除了实际业务数据外，还有很多额外空间。
如 record_type 用来表示该记录的类型是数据还是索引。正是这些额外的空间的设计，给InnoDB以更加适合的方式组织索引提供了支持：

本文插图
图片来自《从根儿上理解 MySQL》
这就是一棵B+树，页节点有层级区分，页中的行记录有类型区分。
业务数据都包含在叶子节点中，目录数据都包含在其他非叶节点中。
这样组织方式的优势，是允许足够少的层级容纳足够多的数据项( 可以简单的假设每一页的数据项大小来预估) 。
而这个索引方式就是我们常说的聚蔟索引。即使用主键值进行记录和页的排序，且叶子节点含有全部用户数据。
寻求改进：如果我想用其他列来查询，怎么办？
6扩展：二级索引、联合索引二级索引
比如用户需要根据某一列（a列）的值来查询，那就再重新创建一个B+树。此索引树和聚蔟索引树的差别在于，索引节点是以a列的值为目录，且叶子节点只包含a列的值和主键两个值。
如果用户需要查询除c列以外的更多信息，则需要拿主键ID再去聚蔟索引查一次，也叫回表。
联合索引
二级索引是除主键外的单列索引，而联合索引则是多个列共同排序。假设用户需要用a 、b 两个列进行有序查询，那内在含义是，在a列值相同的情况下，再判断b的值。
同二级索引一样， InnoDB也需要再创建一棵B+树，且目录项的排序按先a ，后b进行排序串联，叶子节点的数据项只包含 a 、b、主键三个值。
Part4生产实践之触类旁通7美团定时任务索引优化 [3]
系统需要定时的捞取特定时间段内特定状态、特定类型、特定操作者的任务进行定时处理。
select* fromtask
where
status=x
andoperator_id=xxxx
andoperate_time>xxxxxxxx01
andoperate_time<xxxxxxxx99
andtype=x;
开发发现此sql运行的越来越慢，希望给每个字段加二级索引，被优化师叫停，而是考虑的该表所有查询方式后，创建了一个联合索引：
(status,operator_id,type,operate_time)
为什么不建多个的二级索引？为什么范围查询的字段要放在最后？
分析：
（1）从前面的原理部分我们知道，索引是要占内存的，不是越多越好，能起作用就行。