分库分表

1. 到底为啥我们要搞繁琐的分库分表？

单表达到了几千万，甚至亿级的规模，深入的剖析了MySQL的索引原理，索引的B树的高度过高，你在查询数据的时候哪怕是通过索引来查询，都很慢

单表控制在千万以内，百万级别是最好不过的了

如果你的数据库里有很多的表，每个表数据量都很大，服务器的存储空间是有限的，服务器的存储空间几近于耗尽

8核16G的机器部署的数据库，一般每秒TPS也就在几千的样子，不要超过2k/s，如果达到6k、8k每秒的TPS的话，数据库的磁盘、IO、网络、CPU、内存负载会比较高，数据库可能有崩溃的危险

2. 分库分表的时候一般是怎么玩儿的？

永远记得，先垂直，再水平

垂直的意思，就是说把你系统拆成不同的子系统，然后每个子系统连接自己独立部署的数据库，这样就可以把不同业务的数据放在各自的数据库里了，不会说一个数据库里放的数据过多

其次才是水平拆分

1024个表，1 0000 0000，拆到几台服务器上的库去，搞4个服务器，200多张表就可以了

另外就是要注意储备一下技术，分库分表的技术，一般就是sharding sphere或者mycat，我们会讲解架构原理的，重点关注sharding sphere，因为两者是差不多的，所以挑选一个就可以了，另外一个大家就可以自行关注了

3. 订单表要根据用户、商家、订单三个维度查，怎么分？

1亿个订单会被均匀的分散在1024张表里去，要对一个订单做插入，先对这个订单生成一个唯一的id，leaf那套唯一id生成方案了，更新和删除

根据用户id，商家id，订单id，去分三次表

用户要查询自己的订单，还要有一个分页，

如果存储成本不care的话，是ok的，但是如果要是纠结存储成本，可以就订单id分表全量数据，然后用户id分表后就对应订单id，商家id分表后就对应订单id，等于是还要做二次路由

4. 分布式事务

比如说，这个时候，在一个事务里，针对你的订单表和订单条目表，都需要做一个插入或者是更新的一个操作，订单表在某一个库里，订单条目表在另外一个库里，此时可能一个事务里要更新多个库

必然需要分布式事务，XA，跨多个库做事务管控

5. 查询条件里没包含sharding字段怎么办？

组合条件+模糊搜索

要不然就是基于sharding-jdbc之类的中间件去做merge，他会并行查询所有的库里的所有的表，然后内存级进行merge，太慢了，这个太坑，基本不建议这么搞；针对那种不包含sharding字段的复杂查询，特别是多条件组合，甚至还有全文检索的模糊匹配需求，那就直接把索引都建到ES里去

基于ES来筛选数据就可以了，因为ES会建立正排和倒排索引，所以非常擅长这种搜索

一般都是对mysql进行binlog监听，把数据同步到ES里去

6. 分库分表的好朋友：读写分离架构

分库分表+ 读写分离一块儿玩儿的

你有多个主库，主库里存放了大量的分表，每个主库都挂了一两个从库，抗80%以上的常规的crud，数据binlog同步到ES支撑复杂查询

7. 分库分表方案设计好之后的物理架构规划

你要分多少张表，1024张，数据库服务器的数量你需要规划一下

Db的配置、tps、qps、磁盘、网络

数据量，增长速度

写并发

ES 的内存
2308117890

8. 从单库到分库分表的无缝衔接迁移方案

你要分多少张表，1024张，数据库服务器的数量你需要规划一下，主库服务器、从库服务器、ES服务器、数据同步服务器，物理资源都到位了，申请下来了，单库单表里的数据，如何无缝迁移到分库分表的环境里去？

双写

针对分库分表环境的系统代码肯定要进行修改，sharding-sphere中间件做一个代码的修改，部署，连接的就是分库分表的环境；老系统-> 单库单表，也在运行；做一个线上流量的拷贝和分发

Nginx做一个流量分发策略

同一个请求，分发给两套系统，你需要做数据监测，数据数量不能少多，数据内容不能变化，新系统-> 分库分表这套环境彻底ok了

2308117890

9. 针对分库分表的运维管理工作台是什么？

做大量的线上的DDL的操作，建表、修改表，删除表，自己手动1024个表一个一个去做吧，肯定需要运维管理工作台，可以让你对逻辑上的表做DDL，底层自动把DDL在1024张表了去做一个更新，监控，对每个逻辑上的表都知道他切分为了多少张物理上的表，分散在哪些库上，库在哪台服务器上，逻辑表的总数据量多少行，每个物理表的数据量多少行，有一个监控

10. 分库分表的大难题：扩容，扩容还是扩容

一般我们都是设计很多表，扩容的时候就是加更多的服务器和库，然后对表整体做迁移，再修改一下代码里的路由就行了，否则数据迁移是很麻烦的

（1） Sharding-Sphere技术：完整的功能，架构原理，核心源码
（2） 针对订单系统，去做一个订单表的分库分表的完整方案，数据迁移，双写，运维管理，扩容，深度结合Sharding-Sphere技术
（3） 基于Sharding-Sphere、ES等技术做代码级落地开发
（4） 结合真实的电商云平台去讲，真实复杂的订单业务去讲他的代码完善和细化，方案的完善和细化，提供真实的服务器、真实的数据库、真实的10亿订单数据量的环境，给大家去做一个生产实战

11. 通过Sharding-Sphere官网做初步了解

官网地址：http://shardingsphere.apache.org/index_zh.html

按业务id去分库分表，有可能会针对不同维度建立索引映射表，针对跨库跨表复杂查询全部是用ES去做的，数据库中间件（Sharding-Sphere / MyCat），数据迁移，运维管理，在线扩容

数据库中间件的技术积累：Sharding-Sphere的介绍，功能+原理，Demo，源码

开始讲解订单系统的分库分表的方案

订单系统分库分表的落地开发

基于电商云平台的实战

客户端的数据库中间件：Sharding-JDBC

仅仅是一个框架，在你的业务系统里引入一个依赖，就可以用他了，通过给他一些配置，他自动根据配置可以帮助你执行的SQL，自动根据SQL里的业务id的值，根据路由规则，路由到某个库的某个表里去，改写SQL，连接那个指定的库，针对库里的一个表执行SQL

MyCat，Proxy，Server模式

需要独立部署，你的业务系统引入他的客户端依赖，你的所有的SQL都是发送到Proxy Server上去，他代理你的SQL，路由，执行SQL

概览
Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，它由 JDBC、
Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。

Apache ShardingSphere 旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。关系型数据库当今依然占有巨大市场份额，是企业核心系统的基石，未来也难于撼动，我们更加注重在原有基础上提供增量，而非颠覆。

Apache ShardingSphere 5.x 版本开始致力于可插拔架构，项目的功能组件能够灵活的以可插拔的方式进行扩展。目前，数据分片、读写分离、数据加密、影子库压测等功能，以及对 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 与协议的支持，均通过插件的方式织入项目。开发者能够像使用积木一样定制属于自己的独特系统。Apache ShardingSphere 目前已提供数十个 SPI 作为系统的扩展点，而且仍在不断增加中。

12. 通过ShardingSphere官网学习功能和原理

地址：https://shardingsphere.apache.org/document/current/cn/features/sharding/

数据分片
背景
传统的将数据集中存储至单一数据节点的解决方案，在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。

从性能方面来说，由于关系型数据库大多采用 B+ 树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降；同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。

从可用性的方面来讲，服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数据库的可用性，已成为整个系统的关键。

从运维成本方面考虑，当一个数据库实例中的数据达到阈值以上，对于 DBA 的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例的数据的阈值在 1TB 之内，是比较合理的范围。

在传统的关系型数据库无法满足互联网场景需要的情况下，将数据存储至原生支持分布式的 NoSQL 的尝试越来越多。但 NoSQL 对 SQL 的不兼容性以及生态圈的不完善，使得它们在与关系型数据库的博弈中始终无法完成致命一击，而关系型数据库的地位却依然不可撼动。

数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。

数据分片的有效手段是对关系型数据库进行分库和分表。
分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈。

除此之外，分库还能够用于有效的分散对数据库单点的访问量；分表虽然无法缓解数据库压力，但却能够提供尽量将分布式事务转化为本地事务的可能，一旦涉及到跨库的更新操作，分布式事务往往会使问题变得复杂。使用多主多从的分片方式，可以有效的避免数据单点，从而提升数据架构的可用性。

通过分库和分表进行数据的拆分来使得各个表的数据量保持在阈值以下，以及对流量进行疏导应对高访问量，是应对高并发和海量数据系统的有效手段。

数据分片的拆分方式又分为垂直分片和水平分片。

垂直分片

按照业务拆分的方式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。

在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库。

下图展示了根据业务需要，将用户表和订单表垂直分片到不同的数据库的方案。
垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对互联网业务需求快速变化的；而且，它也并无法真正的解决单点瓶颈。

垂直拆分可以缓解数据量和访问量带来的问题，但无法根治。

如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。

水平分片
水平分片又称为横向拆分。相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。例如：根据主键分片，偶数主键的记录放入 0 库（或表），奇数主键的记录放入 1 库（或表），如下图所示。

水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。

挑战

虽然数据分片解决了性能、可用性以及单点备份恢复等问题，但分布式的架构在获得了收益的同时，也引入了新的问题。

面对如此散乱的分库分表之后的数据，应用开发工程师和数据库管理员对数据库的操作变得异常繁重就是其中的重要挑战之一。他们需要知道数据需要从哪个具体的数据库的分表中获取。

另一个挑战则是，能够正确的运行在单节点数据库中的 SQL，在分片之后的数据库中并不一定能够正确运行。例如，分表导致表名称的修改，或者分页、排序、聚合分组等操作的不正确处理。

跨库事务也是分布式的数据库集群要面对的棘手事情。合理采用分表，可以在降低单表数据量的情况下，尽量使用本地事务，善于使用同库不同表可有效避免分布式事务带来的麻烦。在不能避免跨库事务的场景，有些业务仍然需要保持事务的一致性。

而基于 XA 的分布式事务由于在并发度高的场景中性能无法满足需要，并未被互联网巨头大规模使用，他们大多采用最终一致性的柔性事务代替强一致事务。

目标

尽量透明化分库分表所带来的影响，让使用方尽量像使用一个数据库一样使用水平分片之后的数据库集群，是 Apache ShardingSphere 数据分片模块的主要设计目标。

逻辑表

水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为 10 张表，分别是 t_order_0 到 t_order_9，他们的逻辑表名为 t_order。

真实表

在分片的数据库中真实存在的物理表。即上个示例中的 t_order_0 到 t_order_9。

数据节点

数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0。

绑定表

指分片规则一致的主表和子表。例如：t_order 表和 t_order_item 表，均按照 order_id 分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。举例说明，如果 SQL 为：

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
在不配置绑定表关系时，假设分片键 order_id 将数值 10 路由至第 0 片，将数值 11 路由至第 1 片，那么路由后的 SQL 应该为 4 条，它们呈现为笛卡尔积：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在配置绑定表关系后，路由的 SQL 应该为 2 条：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

其中 t_order 在 FROM 的最左侧，ShardingSphere 将会以它作为整个绑定表的主表。所有路由计算将会只使用主表的策略，那么 t_order_item 表的分片计算将会使用 t_order 的条件。故绑定表之间的分区键要完全相同。

广播表

指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。

分片键

用于分片的数据库字段，是将数据库（表）水平拆分的关键字段。
例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。
SQL 中如果无分片字段，将执行全路由，性能较差。
除了对单分片字段的支持，Apache ShardingSphere 也支持根据多个字段进行分片。

分片算法

通过分片算法将数据分片，支持通过 =、>=、<=、>、<、BETWEEN 和 IN 分片。分片算法需要应用方开发者自行实现，可实现的灵活度非常高。

目前提供4种分片算法。由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。

标准分片算法
对应 StandardShardingAlgorithm，用于处理使用单一键作为分片键的 =、IN、BETWEEN AND、>、<、>=、<=进行分片的场景。需要配合 StandardShardingStrategy 使用。

复合分片算法
对应 ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合 ComplexShardingStrategy 使用。

Hint分片算法
对应 HintShardingAlgorithm，用于处理使用 Hint 行分片的场景。需要配合 HintShardingStrategy 使用。

分片策略

包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键 + 分片算法，也就是分片策略。目前提供 5 种分片策略。

标准分片策略
对应 StandardShardingStrategy。提供对 SQ L语句中的 =, >, <, >=, <=, IN 和 BETWEEN AND 的分片操作支持。 StandardShardingStrategy 只支持单分片键，提供 PreciseShardingAlgorithm 和 RangeShardingAlgorithm 两个分片算法。 PreciseShardingAlgorithm 是必选的，用于处理 = 和 IN 的分片。 RangeShardingAlgorithm 是可选的，用于处理 BETWEEN AND, >, <, >=, <=分片，如果不配置 RangeShardingAlgorithm，SQL 中的 BETWEEN AND 将按照全库路由处理。

复合分片策略
对应 ComplexShardingStrategy。复合分片策略。提供对 SQL 语句中的 =, >, <, >=, <=, IN 和 BETWEEN AND 的分片操作支持。 ComplexShardingStrategy 支持多分片键，由于多分片键之间的关系复杂，因此并未进行过多的封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度。

Hint分片策略
对应 HintShardingStrategy。通过 Hint 指定分片值而非从 SQL 中提取分片值的方式进行分片的策略。

不分片策略
对应 NoneShardingStrategy。不分片的策略。

SQL Hint
对于分片字段非 SQL 决定，而由其他外置条件决定的场景，可使用 SQL Hint 灵活的注入分片字段。例：内部系统，按照员工登录主键分库，而数据库中并无此字段。SQL Hint 支持通过 Java API 和 SQL 注释（待实现）两种方式使用。详情请参见强制分片路由。

分片规则
分片规则配置的总入口。包含数据源配置、表配置、绑定表配置以及读写分离配置等。

数据源配置
真实数据源列表。

表配置
逻辑表名称、数据节点与分表规则的配置。

数据节点配置
用于配置逻辑表与真实表的映射关系。可分为均匀分布和自定义分布两种形式。

均匀分布
指数据表在每个数据源内呈现均匀分布的态势，例如：

db0
├── t_order0
└── t_order1
db1
├── t_order0
└── t_order1
那么数据节点的配置如下：

db0.t_order0, db0.t_order1, db1.t_order0, db1.t_order1
自定义分布
指数据表呈现有特定规则的分布，例如：

db0
├── t_order0
└── t_order1
db1
├── t_order2
├── t_order3
└── t_order4
那么数据节点的配置如下：

db0.t_order0, db0.t_order1, db1.t_order2, db1.t_order3, db1.t_order4
分片策略配置
对于分片策略存有数据源分片策略和表分片策略两种维度。

数据源分片策略
对应于 DatabaseShardingStrategy。用于配置数据被分配的目标数据源。

表分片策略
对应于 TableShardingStrategy。用于配置数据被分配的目标表，该目标表存在于该数据的目标数据源内。故表分片策略是依赖于数据源分片策略的结果的。

两种策略的 API 完全相同。

自增主键生成策略
通过在客户端生成自增主键替换以数据库原生自增主键的方式，做到分布式主键无重复。

13. 教你如何看ShardingSphere的源码

并不是很关键和重要，分库分表，核心的架构和方案，代码落地，真实的业务细节、真实上亿数据、真实多数据库服务器的实战经验

有一些框架，是需要你去调用他的API的，那么你看源码，顺着他的API的入口，一步一步的往里面去跟他的代码就可以了

一款仅仅包含核心的分库分表路由功能的数据库中间件，我们自己之前都做过，早很多年的时候，分库分表这块在10年之前没有标准上的中间件，一般都是很多业务团队，都会自己去开发

14. 订单数据的分库分表方案设计

range、hash，如何hash，hash字段，几台数据库服务器，多少个库，每个库里多少个表，数据如何路由到库，如何路由到表，现有系统的这些功能，C端用户，B端商家，M端运营，各种业务功能的CRUD的SQL能否在分库分表中运行

设计数据迁移的方案，设计分库分表新系统的上线方案，设计分库分表环境的运维方案，设计分库分表的扩容方案

按照C端，B端，M端去规划

一般来说，订单数据分库分表都是按用户id和商家id分别拆分的，冗余存储一份数据，常规的都是2个数据库服务器，32个库，每个库32个表，一共是1024张表，刚开始你可以就2台数据库服务器，每台数据库服务器上放16个库就ok了

最好是封装一个订单基础数据服务，让订单里不同端去调用，或者是单块系统都耦合在一起，那就负责不同端开发的同学，直接就双写就行了，不过一般用户端和商家端的系统都是分开的，所以最好是提供一个订单中台级的服务

用户端和商家端本质都是调用订单中台去对订单进行增删改查，订单中台里放你的数据分片逻辑，比如用户端下单，那么订单中台可以对订单数据双写到两套分库分表里去，查询的时候，订单中台自动用对应的数据库集群去进行执行

用户端基本上就是直接把订单数据按userid来路由到32个库中的一个，再路由到里面32个表中的一个，基本上单用户单订单的增删改查就搞定了，如果用户端的订单查询呢？简单，一个用户的订单都在一个分表里，所以基本就是定位到用户的表，单表内做复杂条件的订单查询和分页就ok了

商家端一般基本就是查询，反正都按商家粒度分好表了，一个商家的订单都在一个表里，所以一般都是直接对商家订单所在的单表多条件配合查询就行了，自己建好表的索引基本就ok

至于说M端，公司级去看数据，那基本分库分表是满足不了的，需要通过HBase+ES的方案去做，把订单同步到HBase里去，rowkey都是订单id，然后查询条件都放ES，然后联合起来做M端的订单查询分析

从数据量来说，假设你现在有1000万订单开始进行拆分，日增订单就算你10w单吧，那么月增300w单，年增3600w单，10年才3.6亿单，30年才10亿订单，所以基本可以确定，这个订单数据未来10~30年内都是亿级的规模了

10 0000 0000，分散在1024张表里，每张表是百万级的订单，甚至可能在很长时间里达不到百万级，基本单表在10万级的的订单，所以完全符合条件

至于32个逻辑库，最多可以让你扩展到32台数据库服务器，什么概念？首先32台服务器存10亿甚至百亿订单都不是问题，其次，单台数据库服务器如果都上16核32G的高配置，写QPS可以搞到6k+没问题，32台就很恐怖了，每秒写TPS最高可以达到接近20w，有几个公司需要这么高的写QPS？

其次，每个数据库服务器可以挂从库服务器，每个逻辑库还可以挂从库，你每个主库服务器挂2个从库服务器，那你的查询QPS也是完全没问题的

所以，我们讲的这套分库分表的方案，是非常标准化的，适用于国内除了那少数几个顶级互联网巨头之外，其余的互联网公司和传统软件公司，基本都适用

15. 落地分库分表方案的几个关键步骤

项目实战课，4部分：技术积累、架构设计、代码落地、平台实战

分库分表，方案设计

单表尽量控制在千万级的数据量以内，几百万条数据

平均每个订单对应3个订单条目

正常的互联网公司的订单增长数量，每天10w单，千万级的订单，每月300w订单，每年是3600w订单，10年才3.6亿订单，30年才达到10亿级的订单；订单条目而言，乘以3倍就可以了

订单表就已经到1000万级的数据量了，订单条目已经到了3000万级的数据量了

订单系统的分库分表这个事儿，已经迫在眉睫了

1、设计分库分表的方案

range、hash，如何hash，hash字段，几台数据库服务器，多少个库，每个库里多少个表，数据如何路由到库，如何路由到表，现有系统的这些功能，C端用户，B端商家，M端运营，各种业务功能的CRUD的SQL能否在分库分表中运行

设计数据迁移的方案，设计分库分表新系统的上线方案，设计分库分表环境的运维方案，设计分库分表的扩容方案

2、重构数据存储层的代码

最好是不要碰业务逻辑的代码，最多就是重构分库分表的配置，数据源引入数据库中间件来做代理，DAO那一层，以及你的一些SQL语句可能会涉及到重构，Service里的业务逻辑，数据存储

3、数据迁移

把单库单表的数据，都迁移一份一模一样的到分库分表的环境里去，而且还需要确保两边的数据是完全一模一样的，重构好的代码就可以在分库分表的环境里运行，确保数据没有丢，也没有多，完全正确的，下线老的单库单表的环境和代码

重构以后的系统+ 分库分表的环境，就在线上正常的运行起来，完全没问题

4、分库分表环境的运维

拆分了很多个库，拆分了很多个表，此时如果你要随着业务的迭代，要进行一些DDL的操作，新增一些表，或者对表增加字段，代理了分库分表环境的集中式的数据库运维管理的工作台/命令行，跟以前一样执行DDL，他在底层帮你在分库分表里执行DDL

5、分库分表的扩容

数据库服务器的数据量过大，存储空间不够，或者是QPS压力过大，此时可以考虑先上读写分离，把每个主库拉两个从库，分摊读压力，写TPS如果还是过大，此时需要增加更多的数据库服务器，如何进行扩容
2308117890