分库分表、分区能解决很多的问题,这也是我们在优化的时候常常听到的一些可行的方案,不过提到优化就来分库分表是不是不太合适,本文所阐述的就是分库分表、分区,什么时候用,应该怎么用,怎么选择。
最近听到一些学员的面试复述,基本很多的人去面试的时候都会碰到要对MySQL进行优化这样的题目,很多学员很有经验的学员也在这上面栽了跟头。基本回答有几种
上面的几点,其实能够想到的情况下,看似是不错的。而且很多人也觉得这是标准答案。从表面上看,确实没有很大的问题,实实在在的解决了一些性能问题。不过很多人对这些东西所带来的问题并没有高清楚,同时有些技术在数据库性能不同的阶段是否适合,这个是一个必须要考虑的问题。 采坑的几个点总结如下:
这几个点其实都是我们真正做优化的时候需要考虑的。
索引基本上是我们最常见的一个优化手段了,在单表数据量大的时候如果查询很慢,对我们的条件加一个索引基本是一个很常规的操作。
一上来就说分库分表一定要自信看看这一条。分库分表最大的问题在于对原有数据层的影响,基本这种影响是颠覆性的。如果你将分库分表加上,分库分表最直接的就是会让你对老代码的维护工作量暴增。当然,这里的前提是你是做老项目优化。
MySQL单表能做1024个分区,单库基本能存几十个亿的表。每个分区算一个表,把所有表都做成分区表看似都是可能的。
读写分离,基本是目前商业开发最可靠的手段了。让我们有了更好的数据查询效率。最大的缺陷在于读写分离会增加MySQL服务器的预算。同时MySQL在高并发的情况下,slave也会有延迟,错误等。
冷热数据的分离,其实对于很多项目来讲,是减轻MySQL负担的一个很好的策略。能给保障MySQL数据库性能一直良好。 它的问题在于对于某些业务,不能区分冷热界限。同时冷热数据也会在某些场景下产生,人工维护的工作。
免责申明:
本文系转载,版权归原作者所有,如若侵权请联系我们进行删除!