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

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《MySQL学习笔记-6-普通索引和唯一索引》，文章讲解的知识点主要包括MySQL，如果你对数据库方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

复习

1、MYSQL索引结构

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

理论要掌握，实操不能落！以上关于《MySQL学习笔记-6-普通索引和唯一索引》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！