MySQL优化之索引优化(八)

68 阅读3分钟

开启掘金成长之旅!这是我参与「掘金日新计划 · 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使用场景

  1. 普通索引与唯一索引在查询性能上是没有差别的,主要考虑的是对更新性能的影响。所以,建议尽量选择普通索引。
  2. 实际使用中,普通索引和change buffer的配合使用,对于数据量大的表的更新优化是很明显的。
  3. 如果所有的更新后面,都马上伴随着对这个记录的查询,那么应该关闭change buffer。而在其他情况下,change buffer都能提升更新性能。
  4. 由于唯一索引用不上change buffer的优化机制,因此如果业务上需要,从性能角度看优先考虑非唯一索引。但是如果业务不能确保的情况下,如下处理:
    • 首先,业务正确性优先。前提是业务代码可以保证不会写入重复的数据的情况下,讨论性能问题。如果业务不能保证,或者业务需要数据库做约束,那么没得选,必须创建唯一索引。
    • 然后,在一些归档库的情况,可以考虑唯一索引。比如,线上数据只需要保留半年,然后历史数据保存在归档库。这时候,归档数据已经是确保没有唯一键冲突了。要提高归档效率,可以考虑把表里面的唯一索引改成普通索引。

今天先学习到这里,明天继续。