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所在数据页不在内存中
-
- page1在内存中，直接更新内存
-
- page2不在内存中，就在change buffer区域下，记录“我要往page2插入一行”这个信息
-
- 将上述两个动作记入redo log中
-
插入后马上进行查询
select * from t where k in(k1,k2)-
- 读page1时， 直接从内存中返回
-
- 读page2时，需要把page2从磁盘读入内存，然后应用change buffer里的操作日志，生成并返回结果
-
-
综上，redo log主要节省随机写磁盘的IO消耗，
而change buffer主要节省随机读磁盘的IO消耗。
举个栗子
-
change buffer写入内存了，断电重启了怎么办？会丢失吗
- 不会丢失，在事务提交的时候，会把change buffer的操作页记录到redo log里。