共计 1771 个字符，预计需要花费 5 分钟才能阅读完成。
I、索引的一些基本概念
索引就是数据结构
索引是为了进步数据查问效率
例子：字典。外面的声母查问形式就是聚簇索引。偏旁部首就是二级索引，偏旁部首 + 笔画就是联结索引。II、常见索引模型
| 模型 | 表列 B | 场景 | 场景 |
|---|---|---|---|
| 哈希表 | 键 - 值（类比 hashmap） | 等值查问 | 不能范畴查问 |
| 有序数组 | 按顺序存储，用二分法查问 | 动态存储引擎 | 查问效率高，更新效率低 |
| 搜寻树 | 每个节点的左儿子小于父节点，父节点又小于右儿子 | 等值和范畴查问 | 数高过高，读写磁盘次数过多 |
InnoDB 应用 B +Tree 索引。InnoDB 的表构造：1. 在 InnoDB 中，每一张表其实就是多个 B + 树，即一个主键索引树和多个非主键索引树。2. 执行查问的效率，应用主键索引 > 应用非主键索引 > 不应用索引。3. 如果不应用索引进行查问，则从主索引 B + 树的叶子节点进行遍历。III、索引类型
| 索引 | 存储形式 | 区别 |
|---|---|---|
| 主键索引（聚簇索引） | 叶子节点存的是整行的数据 | 只有搜寻 ID 这个 B +Tree 即可拿到数据 |
| 非主键索引（二级索引） | 叶子节点内容是主键的值 | 先搜寻索引拿到主键值，再到主键索引树搜寻一次 |
从性能和存储空间方面考量，举荐应用自增主键，就能够保障新的 ID 肯定是在叶子节点最左边，不会影响后面的数据。IV、B+Tree 索引保护
一个数据页满了，依照 B +Tree 算法，新减少一个数据页，叫做页决裂，会导致性能降落。空间利用率升高大略 50%。当相邻的两个数据页利用率很低的时候会做数据页合并，合并的过程是决裂过程的逆过程。
须要温习一下二叉树、红黑树、B+ 树等数据结构V、笼罩索引、前缀索引和索引下推
1、笼罩索引：如果查问条件应用的是一般索引（或是联结索引的最左准则字段），查问后果是联结索引的字段或是主键，不必回表操作，间接返回后果，缩小 IO 磁盘读写读取正行数据
2、最左前缀：联结索引的最左 N 个字段，也能够是字符串索引的最左 M 个字符（MYSQL 做词法剖析语法分析的时候是通过建设最左子树来建设语法树的，解析的过程也是从左到右所以遵循最左前缀的准则。）
3、联结索引：依据创立联结索引的程序，以最左准则进行 where 检索，比方（age，name）以 age=1 或 age= 1 and name=‘张三’能够应用索引，单以 name=‘张三’不会应用索引，思考到存储空间的问题，还请依据业务需要，将查找频繁的数据进行靠左创立索引。比方一个联结索引(a,b,c)，其实质是按 a,b,c 的程序拼接成了一个二进制字节数组，索引记录是按该字节数组逐字节比拟排序的，所以其是先按 a 排序，再按 b 排序，再按 c 排序的，至于其为什么是按最左前缀匹配的也就不言而喻了。
4、索引下推：like ‘hello%’and age >10 检索，MySQL5.6 版本之前，会对匹配的数据进行回表查问。5.6 版本后，会先过滤掉 age<10 的数据，再进行回表查问，缩小回表率，晋升检索速度。
VI、mysql 军规
给表创立索引时，应该创立哪些索引，每个索引应该蕴含哪些字段，字段的程序怎么排列，这个问题没有标准答案，须要依据具体的业务来做衡量。不过有些思路还是可供参考的：
1. 既然是一个衡量问题，没有方法保障所有的查问都高效，那就要优先保障高频的查问高效，较低频次的查问也尽可能的应用到尽可能长的最左前缀索引。能够借助 pt-query-digest 来采样统计业务查问语句的拜访频度，可能须要迭代几次能力确定联结索引的最终字段及其排序。
2. 业务是在演进的，所以索引也是要随着业务演进的，并不是索引建好了就高枕无忧了，业务发生变化时，咱们须要从新扫视当初建的索引是不是还仍然高效，仍然能满足业务需要。
3. 业内流传的有一些 mysql 军规，其实这些并不是真正的军规，只是典型场景下的最佳实际。真正的军规其实就一条：高效的满足业务需要。比方有个军规规定一个表上的索引数不超过 5 个，但如果咱们当初有一些历史数据表、历史日志表，咱们很明确的晓得这些表上不会再有数据写入了，但咱们的查问需要很多也很多样化，那咱们在这些表上的索引数能不能超过 5 个？当然是没有任何问题的。当然对于这份军规还是要认真看一下的，但看的重点不是去记住它，而是要弄明确每一条军规它为什么这么规定，它这样规定是基于什么思考，实用的场景和前提是什么，这些都弄明确了，你记不记得住这些军规都无所谓了，因为你曾经把它消溶到了你的血液中，具体到本人的具体业务时熟能生巧将是必然。