数据库写入请求量过大，导致系统出现性能与可用性问题
常见的方式就是对数据库做“分库分表”，在实现上有三种策略：垂直拆分、水平拆分、垂直水平拆分
分库分表的整体设计方案和技术实现的落地思路。一般会涉及这样几个问题：
-
什么场景该分库？什么场景该分表？
-
复杂的业务如何选择分片策略？
-
如何解决分片后的数据查询问题？
如何确定分库还是分表？
-
何时分表
当数据量过大造成事务执行缓慢时，就要考虑分表，因为减少每次查询数据总量是解决数据查询缓慢的主要原因。
-
何时分库
为了应对高并发，一个数据库实例撑不住，即单库的性能无法满足高并发的要求，就把并发请求分散到多个实例中去
分库分表使用的场景不一样： 分表是因为数据量比较大，导致事务执行缓慢；分库是因为单库的性能无法满足要求。
如何选择分片策略？
-
垂直拆分
垂直拆分是根据数据的业务相关性进行拆分
-
水平拆分
垂直拆分随架构改造而拆分，关注点在于业务领域，而水平拆分指的是把单一库表数据按照规则拆分到多个数据库和多个数据表中，比如把单表 1 亿的数据按 Hash 取模拆分到 10 个相同结构的表中，每个表 1 千万的数据。并且拆分出来的表，可以分别存放到不同的物理数据库中，关注点在于数据扩展。
如何解决数据查询问题
将聚合查询的数据同步到 ES 中，或者将计数的数据单独存储在一张表里。如果是每日定时生成的统计类报表数据，也可以将数据同步到 HDFS 中，然后用一些大数据技术来生成报表。
Hash 分片在互联网中应用最为广泛，简单易实现，可以保证数据非常均匀地分布到多个分片，但其过滤掉了业务属性，不能根据业务特性进行调整。而 Range 分片却能预估业务，更高效地扫描数据记录（Hash 分片由于数据被打散，扫描操作的 I/O 开销更大）。除了 Hash 分片和 Range 分片，更为灵活的方式是基于分片元数据。
标签：读少,分库,Hash,拆分,分片,分表,数据 From： https://www.cnblogs.com/jiaozg/p/17215157.html