分库分表的一些思考

链接: 数据库分库分表Java实战经验总结.

在高并发场景下，大量请求都需要操作数据库，导致连接数不够了，请求处于阻塞状态。

如果数据库中存在一张上亿数据量的表，一条 SQL 没有命中索引会全表扫描，这个查询耗时会非常久。

业务量剧增，单库数据量越来越大，给存储造成巨大压力

IO瓶颈
第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询会产生大量的IO，降低查询速度 -> 分库和垂直分表
第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库

CPU瓶颈
第一种：SQl问题：如SQL中包含join,group by, order by，非索引字段条件查询等，增加CPU运算的操作->SQL优化，建立合适的索引，在业务Service层进行业务计算。
第二种：单表数据量太大，查询时扫描的行太多，SQl效率低，增加CPU运算的操作。
-> 水平分表。

当系统并发量上来了，不分库 只分表是难以根本上解决问题。

能不分就不分，并不是所有表都需要切分，主要还是看数据的增长速度，分库分表是业务发展到一定阶段，数据积累到一定量级而衍生出来的解决方案。

分库分表会提升系统的复杂度，不到万不得已不要轻易使用分库分表这个“大招”，避免“过度设计”和“过早优化”。就像我们搭建项目，从快速实现的角度来说，肯定是从单体项目起步的，在业务丰富完善之前，也用不到微服务架构。

分库分表对于DBA来说意味着工作量的成倍增加，原来只需要管理一个DB，现在却要管理N个DB，而且每个DB都需要备份，监控，甚至做高可用，扩展等工作。

分库分表之前，先尽力做力所能及的优化：升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后，在考虑分库分表。

阿里巴巴《Java 开发手册》数据库设计规范中提出单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

数据库优化方案很多，主要分为两大类：软件层面、硬件层面。
软件层面包括：SQL 调优、表结构优化、读写分离、数据库集群、分库分表等。
硬件层面主要是增加机器性能。

sharding-jdbc（当当）
TSharding（蘑菇街）
Atlas（奇虎360）
Cobar（阿里巴巴）
MyCAT（基于Cobar）
Oceanus（58同城）
Vitess（谷歌）