Mysql 索引总结

• 0.索引常见模型

哈希表： key-value存储 多个key经过hash计算会得到同一个值 使用链表遍历来区分value 哈希的key-value类似数组 key不是有序的

当做范围查询时，需要全表扫描特别耗时，适用于等值查询

有序数组： 更新数据需要挪动所有记录 只适合静态存储引擎 
二叉树：查询O(log(N)) 更新O(log(N))

InnoDB中 每一个索引对应的是一个B+树
索引最左前缀  通过调整联合索引字段顺序，可以少维护一个索引（a,b）就可以不用单独维护a索引
联合索引查询到多个条件需要回表 在mysql5.6以后 索引下推 提高效率

---

• 1.普通索引和唯一索引查询过程

      普通索引：因为普通索引中索引树存储的是主键值，先根据k找到主键值，再去主键索引树找到该行 由于普通索引的不唯一性，
需要找到不满足条件的值 需要回表  不想回表的话 做覆盖索引
      唯一索引：根据k从树根开始找到满足条件的值即返回 唯一索引不一定是主键索引 主键索引一定是唯一索引
      InnoDB数据是按数据页为单位来写的，以页为单位 一页16KB 对于Int类型 一个数据页可以放下进千个key

---

• 2.索引维护

B+树为了维护索引的有序性 在键入新值时需要维护，由于不确定主键插入的值，会导致新增数据页或者分裂数据页，所以最好使用
自增ID作为主键， 普通索引的叶子节点存储的是主键值 所以主键值越小 普通索引占用的空间也越小

---

• 3.更新过程

更新的索引数据 如果不在当前数据页，为了减少磁盘读写，InnoDB会将数据写入change buffer中，当需要访问数据页时，将change buffer中的数据写入 这个过程称为merge 后台有线程定期执行merge操作 数据库正常关闭也会执行 特别是在使用机械
硬盘的时候，change buffer的提升是巨大的

唯一索引需要判断表中是否存在一致的ID 所以必须将数据读取到内存中  所以不能使用change buffer
普通索引在读多写少的场景 写完之后马上被访问的几率较小 日志类账单类  在写完马上读场景中 反而增加了io次数 起了副作用
如果所有的写入都伴随着更新 建议关闭change buffer
redo log 主要节省的是随机写磁盘的 IO 消耗（转成顺序写），而 change buffer 主要节省的则是随机读磁盘的 IO 消耗。
redolog有两种，一种记录普通数据页的改动，一种记录changebuffer的改动