一 简述
传统的关系型数据库，比如常用的 MySQL 都存在性能瓶颈，即在数据达到一定的量级之后，数据库的性能会显著下降，数据库的读写操作都会随之受到影响。这是一个常见的性能优化场景。对此，也有一些常见的优化思路：
- NoSQL。使用常见的 NoSQL 产品比如 Redis 来缓解数据库终端的压力。将线上的热点数据预热到缓存中，避免大量的客户端请求直接打到数据库上面，减轻数据库压力。
- 读写分离。配置主从数据库。然后将应用程序的请求分离为读/写两种类型，读请求走从库(slave)，写类型请求走主库(master)。而主从数据库之间的数据同步则依赖数据库产品自身提供的功能来完成。比如 MySQL 自身提供的主从数据同步方案。主从库之间存在较低(可接受范围)的数据同步延迟。这里有一个衍生问题：MySQL 的复制方式。
- 数据分片。既然单表/单库存在数据保存的性能瓶颈，那就将想要保存的数据分散到多个库表中。数据分片的方式又区分为水平分片和垂直分片。
二 水平分片与垂直分片
2.1 垂直分片
关于垂直分片的具体定义，其实存在不同业务场景下的理解差异。
- 一种场景：存在一个宽表(即包含过多字段的表)，其中某几个字段属于热点数据，客户端请求某一条记录，大部分情况下都是要获取这条记录中的某几个热点字段。这个时候，将这张表拆分为主表和从表两张表，热点数据单独成表(从表)，这样数据访问/更新会避免在宽表上的大量操作。
- 另一种场景：在业务规模大幅扩张之前，把一系列的业务都放在少数几个库上，比如:
t_user
t_order
此时将 t_user 与 t_order 两张表从同一个库拆分到不同的库和机器上。减轻单台机器的压力。
垂直分库
2.2 水平分片
水平分表分库
不按照业务数据拆分，而是将同一类型的数据，分别放到不同的库/表中。每个分片包含了整体数据集的一部分。比如：
- 根据主键 id 拆分，奇数 id 的数据保存在奇数表(db01.t_user_01,db02.t_user_03)，偶数 id 的数据保存在偶数表(db01.t_user_02,db02.t_user_04)。
- 根据数据创建时间拆分，比如每个月的数据单独成表，每年的数据单独成库。2020年1月创建的数据存在于表 db2020.t_user_01，2020 年 2 月生成的数据存在于表 db2020.t_user_02。即 按月分表，按年分库。
上面两种水平拆分方式各有利弊。在不同的场景下效果也不同。
举例：假如我们以 uid 水平拆分的策略，保存了用户的浏览历史信息。那么当用户在客户端点击查询自己的浏览记录时，就可以一次性查询到最近一个月/半年的浏览记录。因为基于这种拆分策略，同一个用户的浏览记录全部都保存在同一张表中，因此一次查询基本上就可以满足需求；如果是按时间水平分表，保存这类数据，那么在客户端一般就需要做出取舍，比如用户只能查看最近一个月的浏览记录，因为每张表都只保存最多一个月的数据，如果要查看更多，就需要跨表查询。对于大用户量级的产品来说，我们很难满足其需求。
三 不同分片策略各自的问题
3.1 垂直分片
即拆分表为主表/从表组合，或将原本放在同一个库下的两张表拆分到不同的数据库。
这里有一个前置点：我们需要提前对自己要处理的业务有充分的了解。在设计数据库的时候，尽量提现考虑好这类问题
- 提前设计好对应的主表/从表组合
- 提前按不同的业务模块拆分数据库，比如拆分成用户库/订单库/物流库并分布到不同的业务群组。这样也可以减轻机器压力。
如果是在业务发展过程中要做这样的拆分，就很麻烦了，涉及大量的改动。牵一发而动全身，并不能很好地推行。
不同业务库的分离，自然也涉及到了分布式事务处理。
3.2 水平分片
分表分库，也可以分化为两种策略。
- 分表，即将同一批数据拆分为多个表，但是仍然放在同一个数据库内。这样可以 避免跨库事物，但是如果数据操作仍然集中在一个库内，那就无法有效减轻单节点的压力。
- 进一步的分库，可以有效减轻单节点压力，但又不可避免的会遇到分布式事务问题。
所以具体要采用那种粒度级别，就需要根据自己的需求决定。一般来说，会同时分表+分库。
