架构师必备技能：数据库优化手术刀——实战分库分表

点击最上方蓝字进行关注的都是靓仔和仙女呦

在最初，应用的数据量比较少，没有任何压力，一般会将所有的数据放在一个库中。但是随着业务的增长，数据量急剧增长，DB压力增大，似乎随时都会挂掉。此时，优化DB的使用已经是势在必行，以下有几个方案。

1

优化对DB的使用

优化对DB的使用

读写分离（肯定一开始就做了……）、索引、使用合理的sql等等。一些简单的优化可以先做，复杂的优化如果时间允许能先做是最好的，但如果是一直被业务赶着走，抽不出时间做，只好先选择其它的措施。

2

升级机器配置

升级机器配置，加CPU、加内存，换SSD。简单粗暴，无论怎么样，机器比人便宜，如果没时间做业务上的优化，先走这条路，直到最后升级机器已经没有效果。

3

拆库

随着业务的继续发展，最终，机器也升级到没得升了，基本的sql优化也做了，但数据库还是扛不住。只能开始拆库，可以选择垂直拆分与水平拆分。

其中垂直拆分是最简单的，也是成本最低的，对线上业务的影响也不大。可以按业务模块进行拆分，这样相对清晰。可以将新拆分出来的库作为原来库的从库，保持数据的同步。挑个流量低峰时间做切换，先关闭写入服务，之后将服务切换到新拆分出来的库即可。

按业务模块拆分数据库以后，可以支撑业务的运行很长时间了。除非，某个业务模块已经发展到单DB、抑或单表也无法支撑的程度。这个时候需要着手进行水平拆分了，按什么维度进行拆分需要综合考虑事务支持、数据的分布是否均匀、能否方便后续的数据处理等问题，一般选择用户id，业务编号等。

水平拆分可选择取模，或者波动更小的一致性hash。但是无论是取模还是一致性hash，都涉及到如何选择拆分的规模的问题，也即初始我们要拆分多少个表，多少个库，拆小了，跟不上业务的发展，很快就得继续做拆分。拆大了，机器闲置也浪费资源。

这就牵扯到未来如果加机器，如何平滑过渡，最好都不用停机的问题。毕竟，7*24小时才是互联网服务的正确姿势。 之前网上看到过一个方案可以借鉴下。

就是在前面加一个索引，存储当前数据的映射，新增数据库以后，所有操作都先查索引，获取映射的库进行相应的操作。那么对于旧的数据，还是到原来的db读写。新的数据由于索引不存在，重新计算其索引，并落到对应的DB。另外，其任务对旧数据进行迁移，不过要注意迁移的过程要对数据进行锁定，防止不一致的情况，在流量低峰进行即可。这个方案配合一致性哈希会好一些，需要迁移的数据相对少。 

想更加详细，更加深入的了解分库分表吗？

在这里部落告诉大家一个小秘密

今晚8：30

动脑学院  Sean大神

将在腾讯课堂  动脑学院  免费Java公开课中

给大家详细讲解

《架构师必备技能：数据库优化手术刀——实战分库分表》

你只需要在今晚8：30的时候

点击文章最末 阅读原文

即可进行观看

推荐阅读  

▼

高并发与分布式系统的基石--数据库读写分离实战

这就是学编程的下场...

论程序员与产品经理是怎么互掐起来的

如何假装成为一名好的程序员

来自部落的邀请

Java框架 Spring 核心机制

至程序员的情书

Java高级部落送你ofo小黄车60天免费骑行，还不来？

Facebook研发的Cassandra你用过吗？

给 Java开发者的10个大数据工具和框架

推荐程序员必备微信号 

▼

Java高级部落

微信号：javagaojibuluo

在部落里，将会分享程序员相关的的技术，职场生活，行业热点资讯....以及更多好玩的IT趣文和趣图都在此部落中.....这....只属于我们程序猿.....
 ▼长按下方↓↓↓二维码识别关注

推荐学习资料获取微信号 

长按下方▼二维码识别关注