数据切分（Sharding）

关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到 1000W 或 100G 以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。

数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分

一. 垂直（纵向）切分

垂直切分常见有垂直分库和垂直分表两种。

垂直分库：就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。 做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与”微服务治理”的做法相似，每个微服务使用单独的一个数据库。如图：

垂直分表：基于数据库中的”列”进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。 在字段很多的情况下（例如一个大表有100多个字段），通过”大表拆小表”，更便于开发与维护，也能避免跨页问题，MySQL 底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘 IO，从而提升了数据库性能。

优点：

解决业务系统层面的耦合，业务清晰
与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈

缺点：

部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
分布式事务处理复杂
依然存在单表数据量过大的问题（需要水平切分）

二. 水平（横向）切分

当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。

水平切分分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。如图所示：

库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻 MySql 数据库压力来说，帮助不是很大，大家还是竞争同一物理机的 CPU、内存、网络 IO，最好通过分库分表来解决。

水平切分的优点：

不存在单表数据量大、高并发的性能瓶颈，提升系统稳定性和负载能力。
应用端改动小，不需要拆分业务模块。

水平切分的缺点：

跨分片的事务一致性难以保证
跨库的 join 关联查询性能差
数据多次扩展和维护量极其大

水平切分后同一张表会出现在多个数据库/表中，每个库/表的内容不同。几种典型的数据分片规则为：

1. 根据数值范围：

按照时间区间或 ID 区间来分，例如：按日期将不同月甚至不同日的数据分散到不同的库中；将 userId 为 1 ~ 9999 的记录分到第一个库，10000 ~ 20000 的记录分到第二个库，以此类推。某种意义上，某些系统使用的“冷热数据分离”，将一些使用较少（不活跃）的历史数据迁移到其他库，业务上只提供热点数据的查询，也是类似的实践。

优点：