[大数据]分库分表的场景和常见操作

分库分表

网上分库分表的资料很多，这里主要是重新整理和梳理一下。如有和其他文章类似片段或解决方案，纯属前人总结或者业内标准。

为什么要分表分库

分表分库一般会在以下情况下出现：

一、数据库本身的性能瓶颈

1. 单机数据库的存储容量限制
2. 单机数据库的连接数限制
3. 单张表的性能瓶颈
4. 单张表性能瓶颈；
5. 单个数据库性能瓶颈；

二、特殊场景需求

1. SasS 特定场景下的数据隔离需要；

数据库瓶颈

不管是 IO 瓶颈，还是 CPU 瓶颈，最终都会导致数据库的查询缓慢甚至无法查询。进而导致业务服务的难易提供并发量、吞吐量。数据库瓶颈也会导致查询缓慢、大量的超时情况进而导致程序无法使用或者崩溃的情况

IO 瓶颈

第一种：磁盘读 IO 瓶颈，数据太多，数据库缓存放不下，每次查询时会产生大量的 IO，降低查询速度 -> 分库和垂直分表

第二种：网络 IO 瓶颈，请求的数据太多，网络带宽不够 -> 分库

CPU 瓶颈

第一种：SQL 问题，如 SQL 中包含 join，group by，order by，非索引字段条件查询等，增加 CPU 运算的操作 -> SQL 优化，建立合适的索引，在业务 Service 层进行业务计算。

第二种：单表数据量太大，查询时扫描的行太多，SQL 效率低，CPU 率先出现瓶颈 -> 水平分表。

网上也流传着一些更通俗具体的说法比如：当单表的数据量达到1000W或100G以后。更通俗的说话就是数据库已经无法满足性能需求了。至于什么情况不能满足性能需求，还是要根据具体的场景来确定的，并没有什么金科玉律。

特殊场景需求

这个就没有办法了，直接接受吧 😏🤣😂😅😢😥😪😓😰😭

分表分库前我们可以做哪些尝试

里面涉及的具体实现以 Java 为主，其他语言使用者自行脑补

数据库本身的性能瓶颈是无法避免，但我们可以想法减轻数据库的压力，减轻数据库瓶颈本身带来的影响。

缓存

缓存可以称的上提供性能减少数据库查询的一个万金油方案，其虽然不能完美的，但一定是最先想到的。

一般可以使用进程内缓存和分布式缓存两种方案想结合的方案。对于一致性要求不高，甚至允许一定时间内可以有数据差异的功能，可以直接采用进程内缓存来实现，这种方案更高效，不过其和程序本身占用同一个进程，需要考虑进程内缓存的容量问题，具体方案可以使用 Google Guava、Caffeine 以及 Spring Cache 等；如果对于一致性要求高，并且不想缓存占用更多的进程内存，则可以使用分布式缓存，其通过一个高性能外部的 Server 来存储一些需要缓存的数据，服务通过网络通信来获取外部 Server 的缓存数据，其增加了一部分网络开销，但不用再占用业务服务的进程内存。

数据库读写分离

读写分离也是一种有效降低数据库压力的方案，通过数据库主从结构，主节点负责读写，从节点负责读。这样我们可以通过将一些读请求分散到从节点，来减轻主节点的压力。比如一些报表、分析、统计的功能模块只允许其访问从库，可以在一定的条件下提升整体性能

关于一些常见的数据库架构的模式，这里不在叙述，这和本文无关，具体模式以后可能会再写一篇进行补充。

优化数据库结构和查询语句

1. 对一些查询条件加索引
2. 对一个表中不经常被查询的数据切割到一个子表中，保证主表的查询性能
3. 适当的优化表结构等等

当然 SQL 优化不是本文的重点，但这也是一个优化的方向，好的 SQL 和表结构对应性能还是有很大影响的。

其他混合方案

我们也可以通过混合其他存储方案来减轻数据库的压力，比如 MongoDB、ElasticSearch。通过混合使用一些更高性能的技术方案来提高整体性能

分表分库的常见方案和局限性