共计 1516 个字符，预计需要花费 4 分钟才能阅读完成。
温习
1、MYSQL 索引构造
| 数据结构 | 应用范畴 | 1 | 2 |
|---|---|---|---|
| hash | 较少 | 索引以 hash 模式组织起来，查找单条记录时速度十分快 | 不反对范畴查找和排序等性能 |
| B+ tree | 频繁 | 索引以均衡树的模式来组织，更适宜用来解决排序、范畴查找等性能 | 查找单条记录的速度不如 hash |
2、MYSQL 常见索引类型
| 表列 A | 表列 B |
|---|---|
| 一般索引 | 最根本的索引，没有任何限度 |
| 惟一索引 | 与 ” 一般索引 ” 相似，不同的就是：索引列的值必须惟一，但容许有空值 |
| 主键索引 | 一种非凡的惟一索引，不容许有空值 |
| 全文索引 | 仅可用于 MyISAM 表，针对较大的数据，生成全文索引很耗时好空间 |
| 组合索引 | 为了更多的进步 mysql 效率可建设组合索引，遵循”最左前缀“准则 |
3、非主键索引会存储主键索引的值，因而举荐选用短字段当主键索引。
4、惟一索引：插入的时候，一般索引比惟一索引性能要高一点，惟一索引须要校验内容。
查问过程
1、一般索引跟惟一索引执行上的区别：一般索引的等值查问，会持续遍历到第一个不相等的值才会完结，而惟一索引等值查问，命中则完结（性能差距微不足道）。
2、Innodb 按页读取，一页 16KB。
更新过程
1、change buffer 概念：当须要更新一个数据页时，如果数据页在内存中就间接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB 会将这些更新操作缓存在 change buffer 中，这样就不须要从磁盘中读入这个数据页了。在下次查问须要拜访这个数据页的时候，将数据页读入内存，而后执行 change buffer 中与这个页无关的操作。
2、change buffer 应用条件：惟一索引的更新不能应用，实际上也只有一般索引能够应用。
3、change buffer 应用场景：
——对于写多读少的业务来说，页面在写完当前马上被拜访到的概率比拟小，此时 change buffer 的应用成果最好。这种业务模型常见的就是账单类、日志类的零碎；
——假如一个业务的更新模式是写入之后马上会做查问，那么即便满足了条件，将更新先记录在 change buffer，但之后因为马上要拜访这个数据页，会立刻触发 merge 过程。这样随机拜访 IO 的次数不会缩小，反而减少了 change buffer 的保护代价。
4、总结
——一般索引与惟一索引，一般索引在更新时速度更快，尽量选一般索引
——更新之后马上就是查问时，不应用 change buffer
——change buffer 更适宜一般索引
索引抉择和实际
1、机械硬盘，change buffer 收益高
2、redo log 与 change buffer(含磁盘长久化) 这 2 个机制，不同之处在于优化了整个变更流程的不同阶段。先不思考 redo log、change buffer 机制，简化形象一个变更(insert、update、delete) 流程：1、从磁盘读取待变更的行所在的数据页，读取至内存页中。2、对内存页中的行，执行变更操作 3、将变更后的数据页，写入至磁盘中。步骤 1，波及 随机 读磁盘 IO；步骤 3，波及 随机 写磁盘 IO；
–change buffer 机制，优化了步骤 1, 防止了随机读磁盘 IO；
–redo log 机制，优化了步骤 3, 防止了随机写磁盘 IO，将随机写磁盘，优化为了程序写磁盘(写 redo log，确保 crash-safe)；
– 在咱们 mysql innodb 中，change buffer 机制不是始终会被利用到，仅当待操作的数据页以后不在内存中，须要先读磁盘加载数据页时，change buffer 才有用武之地。redo log 机制，为了保障 crash-safe，始终都会用到。
3、redo log 次要节俭的是随机写磁盘的 IO 耗费（转成程序写）；
change buffer 次要节俭的则是随机读磁盘的 IO 耗费。
