链接: 数据库分库分表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（谷歌）
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/133901.html
