【ShardingSphere】作优化上来就分库分表？请慎重分库分表

分库分表、分区能解决不少的问题，这也是咱们在优化的时候经常听到的一些可行的方案，不过提到优化就来分库分表是否是不太合适，本文所阐述的就是分库分表、分区，何时用，应该怎么用，怎么选择。

话题起点

最近听到一些学员的面试复述，基本不少的人去面试的时候都会碰到要对MySQL进行优化这样的题目，不少学员颇有经验的学员也在这上面栽了跟头。基本回答有几种

• 加索引
• 分库分表
• 分区
• 读写分离
• 冷热数据处理

采坑分析

上面的几点，其实可以想到的状况下，看似是不错的。并且不少人也以为这是标准答案。从表面上看，确实没有很大的问题，实实在在的解决了一些性能问题。不过不少人对这些东西所带来的问题并无高清楚，同时有些技术在数据库性能不一样的阶段是否适合，这个是一个必需要考虑的问题。 采坑的几个点总结以下:

• 笼统的去描述优化，根本不知道使用的优化策略究竟是不是适合的。这个问题在商业开发中很容易出现重大事故
• 若是只考虑这几点，实际上是不太够的，咱们还须要考虑磁盘、成本、IO等问题。这个问题商业开发中也是会出现，同时也会极大的增长投入成本
• 对代码的优化也是必要的，不少的时候，代码、SQL的优化能给咱们带来很好的效益，不过这一点对程序员的要求相对较高。商业开发中，不少地方是能跑的就不要动，要是搞很差会全面回归。

这几个点其实都是咱们真正作优化的时候须要考虑的。

优化策略分析--索引

索引基本上是咱们最多见的一个优化手段了，在单表数据量大的时候若是查询很慢，对咱们的条件加一个索引基本是一个很常规的操做。

• 相信对于重复度很低的字段建索引这错应该是没人犯的，不过不少人却会跳另一个坑：索引过多、或者索引树太高。这个问题比较无奈，若是说多索引合并成为联合索引能解决根本问题吗？多数这种状况下不是说没有办法解决，而是历史遗留问题限制。若是强行合并，解决了索引过多的问题，代码的问题随之可能就会出现。由于你合并索引，可能致使原有逻辑产生索引失效的问题。

优化策略分析--分库分表

一上来就说分库分表必定要自信看看这一条。分库分表最大的问题在于对原有数据层的影响，基本这种影响是颠覆性的。若是你将分库分表加上，分库分表最直接的就是会让你对老代码的维护工做量暴增。固然，这里的前提是你是作老项目优化。

优化策略分析--分区

MySQL单表能作1024个分区，单库基本能存几十个亿的表。每一个分区算一个表，把全部表都作成分区表看似都是可能的。

• 确确实实，在商业开发当中，分区是一个很重要的优化手段。分区能给咱们带来什么：用单表存储亿级的数据而不会产生查询时间过长，清理表也很方便。
• 缺点：分区带来了很好的用户体验，可是随之而来的就是庞大的运维工做量。试想一下，倘若咱们一个项目核心表差很少100张，每张建365个分区。总共算下来，分区就会有36500个。至关于我天天要去维护100个表。

优化策略分析--读写分离

读写分离，基本是目前商业开发最可靠的手段了。让咱们有了更好的数据查询效率。最大的缺陷在于读写分离会增长MySQL服务器的预算。同时MySQL在高并发的状况下，slave也会有延迟，错误等。

优化策略分析--冷热数据处理

冷热数据的分离，其实对于不少项目来说，是减轻MySQL负担的一个很好的策略。能给保障MySQL数据库性能一直良好。 它的问题在于对于某些业务，不能区分冷热界限。同时冷热数据也会在某些场景下产生，人工维护的工做。