MySQL学习笔记-6-普通索引和唯一索引

复习

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 消耗。