开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第17天，点击查看活动详情
前言
上篇我们学习了MySQL中的数据库优化之索引优化。有兴趣的小伙伴可以阅读(MySQL优化之索引优化（七）)。
下面我们继续学习MySQL中的数据库优化之索引优化。
普通索引和唯一索引
更新过程
什么是change buffer？当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB会将这些更新操作缓存在change buffer中，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer中与这个页相关的操作。通过这种方式就能保证这个数据逻辑的正确性。
将change buffer中的操作应用到原数据页，得到最新结果的过程称为merge。除了访问这个数据页会触发merge外，系统有后台线程会定期merge。在数据库正常关闭的过程中，也会执行merge操作。如果能将更新操作先记录在change buffer，减少读磁盘，语句的执行速度会得到明显的提升。而且，数据读入内存是需要占用buffer poll的，所以这种方式还能够避免占用内存，提高内存利用率。唯一索引的更新就不能使用change buffer，实际上也只有普通索引可以使用。
change buffer使用场景
- 普通索引与唯一索引在查询性能上是没有差别的，主要考虑的是对更新性能的影响。所以，建议尽量选择普通索引。
- 实际使用中，普通索引和change buffer的配合使用，对于数据量大的表的更新优化是很明显的。
- 如果所有的更新后面，都马上伴随着对这个记录的查询，那么应该关闭change buffer。而在其他情况下，change buffer都能提升更新性能。
- 由于唯一索引用不上change buffer的优化机制，因此如果业务上需要，从性能角度看优先考虑非唯一索引。但是如果业务不能确保的情况下，如下处理：
- 首先，业务正确性优先。前提是业务代码可以保证不会写入重复的数据的情况下，讨论性能问题。如果业务不能保证，或者业务需要数据库做约束，那么没得选，必须创建唯一索引。
- 然后，在一些归档库的情况，可以考虑唯一索引。比如，线上数据只需要保留半年，然后历史数据保存在归档库。这时候，归档数据已经是确保没有唯一键冲突了。要提高归档效率，可以考虑把表里面的唯一索引改成普通索引。
今天先学习到这里，明天继续。
