1 . 08 讲评论里关于事务可见性的问题 , 提出的好问题
2 当一个字段可以建唯一和普通索引 , 性能角度选哪个 , 如身份证 , 在逻辑代码上保证唯一
3 B+Tree 索引的大概轮廓 , 一个节点有多个 key , key 之间有空隙(指针) 表示大于或小于他的值 , 同一节点的值顺序排列 , 因此可用二分法查找 , sibling 节点之间也有指针互联 ,
4 普通索引和唯一索引的性能差距微乎其微
5 普通索引查找到记录后还会往下查,直到碰到第一个不满足 k=5的记录 , 唯一索引找到后就停止
6 innodb 是按数据页为单位读写 , 读一条记录也需要读整页
7 默认数据页大小 16KB
8 扩展阅读
9 change buffer 是什么 , 如何影响普通和唯一索引的性能
10 在数据页需要更新的时候 , 如果数据页已经在内存中则直接更新 , 如果不在, 则先存到 change buffer , 避免了从磁盘中读入该数据页 , 下次查询用到这个数据页的时候 , 读入并把在 change buffer 中的改动 merge , 保证数据逻辑上的正确
11 change buffer 也会被写到磁盘上 , crash safe 另一个保证
12 访问数据页会触发 merge , 后台也有线程定期 merge
13 什么是 buffer pool
14 唯一索引的更新过程
15 先判断唯一性约束 , 所以需要先读入对应数据页 , 用不到 change buffer ! 只有普通索引能用到
16 change buffer 用的是 buffer pool 里的内存 , 大小有限
17 innodb_change_buffer_max_size 可配置大小 , 是 change buffer / buffer pool 的百分比 , 60=50%
18 当要更新的页在内存中的时候 , 唯一索引只多了一个判断 , 只耗费微小的 CPU 时间 , 可以忽略不计
19 当要更新的页不在内存中 , 唯一索引多了一个将完整的数据页读入内存的随机 IO , 耗费时间巨大
20 而普通索引有 change buffer 缓解了这一步可能造成的阻塞
21 一个由于将索引改为唯一索引造成的更新语句阻塞案例
22 数据库内存命中率从 99%降到 75%
23 内存命中率是什么? hit 到内存中的数据页的概率吧? 而更新语句一般不查 , 所以不会 hit 到 , 因此降低了
24 因为是唯一索引 , 所以更新语句会读数据页到内存中 , 降低了命中率
25 如何查 mysql 的内存命中率
26 change buffer 在某个数据页的更新越多 , 收益就越大 , 因为下次读入该数据页的时候可以一次性merge
27 适合的场景是写多读少 , 比如账单类 , 日志类的系统
28 如果是写完立即访问的 , change buffer 反而起反作用 , 增加了 merge 和 change buffer 的维护代价
29 普通和唯一差别主要在更新性能上
30 建议尽量选普通索引
31 如果是知识点 28 的情况 , 可以考虑关闭 change buffer , 但是一般情况cb 都是能提高性能的
32 特别是在机械硬盘上 , cb 收益更显著 ,
33如”历史数据” 类的库 , 尽量使用普通索引 , cb 开大
21 redo log 和 cb 很像 , 搞混了 (你为什么不喜欢看图啊 , 看图一下就懂了 )
22 redo log 的机制 WAL , 也是尽量减少随机读写的机制
23 但是 redo log 是写磁盘持久化的 , cb 是内存中的 , 可以把 cb 理解为某种辅助栈 (O(1)实现栈的 max操作)
24 redo log 优化随机写为顺序写 , cb 减少随机读
25 innodb buffer pool 是什么
26 redo log (ib_log_fileX)的文件存在哪
27 system table space (ibdata 1) 是什么
28 data (t.ibd ) 是什么 ibd 的全称是什么
29 上面那些缩写都是什么意思
30 redo log 也会记录 change buffer 的动作
31
32 思考题
通过图2你可以看到，change buffer一开始是写内存的，那么如果这个时候机器掉电重启，会不会导致change buffer丢失呢？change buffer丢失可不是小事儿，再从磁盘读入数据可就没有了merge过程，就等于是数据丢失了。会不会出现这种情况呢？
