【MySQL 45讲-9】第9讲普通索引和唯一索引

09 | 普通索引和唯一索引，应该怎么选择？

查询过程

• 举个栗子
  select id from T where k=5

  • 查找过程：从B+树的树根开始，按层搜索到叶节点（数据页），然后根据二分法在数据页内部来定位。

  • 建立普通索引还是唯一索引？

    • 普通索引：查到第一个满足的记录后，需要查找下一个记录，直到碰到不满足k=5，结束

    • 唯一索引：因为有唯一性，所以找到了第一个满足的记录后就结束了

    • 性能差距：微乎其微

      • InnoDB按数据页为单位读写
      • 所以都是读取一页，只是怕普通索引要多做一次查找和判断下一次记录（一次指针寻找和计算）

更新过程

• change buffer

  • 使用场景

    • 只限于用在普通索引的场景下，不使用于唯一索引

      • 因为对于唯一索引，所有的更新操作都要先判断这个操作是否违反唯一性约束，而这需要将数据页读入内存才能判断，既然已经读到内存了，直接更新内存会更快，没必要change buffer

    • 但是并不是所有普通索引都适用

      • 写多读少的业务，页面在写完以后马上被访问到的概率小，如账单类、日志类系统，所以用change buffer的效果好

      • 写入之后马上会做查询的业务不适用

        • 因为马上要访问这个数据页，会立即触发merge过程，这样随机访问IO的次数不会减少，反而增加了change buffer的维护代价。

  • 在内存中有拷贝，也会被写入到磁盘上

  • merge

    • 将change buffer中的操作应用到原数据页，得到最新结果的过程。

    • 触发条件

      • 访问这个数据页
      • 系统后台线程会定期merge
      • 数据库正常关闭也会merge

  • 主要是减少读磁盘，提升运行速度

• 更新流程

  • 如果数据页在内存中

    • 唯一索引

      • 判断有没有冲突再更新

    • 普通索引

      • 直接更新

  • 数据页不在内存中

    • InnoDB会将这些更新操作缓存在change buffer中，下次查询需要访问这个数据页时，将数据页读入内存，然后执行change buffer中与这个页有关的操作。

    • 唯一索引

      • 将数据页读入内存，判断是否有冲突再更新

    • 普通索引

      • 直接将记录更新在change buffer中

索引选择和实践

尽量选择普通索引

如果所有更新后都马上伴随着查询，则应该关闭changebuffer

普通索引和change buffer配合使用对于数据量大的表的更新优化明显

change buffer和redo log

• 表上插入一条语句
  insert into t(id, k) values(id1, k1), (id2,k2)

  • k索引树，k1所在数据页在内存中，k2所在数据页不在内存中
  • 1. page1在内存中，直接更新内存
  • 2. page2不在内存中，就在change buffer区域下，记录“我要往page2插入一行”这个信息
  • 3. 将上述两个动作记入redo log中

• 插入后马上进行查询
  select * from t where k in(k1,k2)

  • 1. 读page1时， 直接从内存中返回
  • 2. 读page2时，需要把page2从磁盘读入内存，然后应用change buffer里的操作日志，生成并返回结果

• 综上，redo log主要节省随机写磁盘的IO消耗，
  而change buffer主要节省随机读磁盘的IO消耗。

举个栗子

• change buffer写入内存了，断电重启了怎么办？会丢失吗

  • 不会丢失，在事务提交的时候，会把change buffer的操作页记录到redo log里。