自从互联网的开发以来，各家公司的各个公司的数据量都大大增加了，我们使用越来越多的表格，因此我们应该如何合理地划分自己的业务场景并合理地分配数据并使用数据并使用最低价格以最低价格。解决性能瓶颈。
子饰面表实际上是两个单词
子 - 著名：将库中的数据分别放在多个库中
子表：将数据分别放在多个表中
至于为什么图书馆被划分了？它必须是单个图书馆或单个桌子，不足以满足我们的业务需求。无论是从性能的角度，还是从数据库存储容量的角度来看，瓶颈每种类型的数据库的数据量达到一定程度。这次，我们必须使用拆分表来改进数据库的存储容量和性能。
一般而言，当我们在数据库中遇到性能问题时，我们将优先考虑数据库的主要副本，读写分离。
主人 - 奴隶复制带来的问题：
子女桌子也是耶和华的复制带来的问题。
总而言之，数据库无法忍受！交叉发行
对于Java项目，分区表通常分为两个阶段
我们应该更多地基于遇到的问题，并灵活地选择分支表的方案。如果没有性能问题，请记住超过设计。
该库可以主要解决读写和编写QP的问题以及数据库连接不足的问题，我们从此开始。
首先分析我们通常的业务高峰，然后考虑是一个巨大的促销或活动。该流量的峰值增加。
公式：峰流/单库轴承容量=库的数量。
微服务方案将根据服务拆分数据库进行分配。
与库相比，该表更麻烦，更常用。由于经常出现一些大数据表，因此数据库的性能瓶颈经常出现。
子标签通常估计数据量的量。然后，根据系统的系统，在单个表的数据量数量中制作了多少表。
当估计数据时，我们必须扩大足够的空间。
配方：每日增长365系统使用寿命/表最大容量=平板电脑数量
通常，当我们切割数据时，我们考虑垂直切割或水平分裂。对于库和表，水平和垂直切割是相同的设计方案。水平切割不会破坏数据的结构。所有部分希望获得全部数据，必须将其切入库和表格。
垂直划分是将表的不同字段切成不同的表。
这种设计方法是拆分一些高频数据。最常见的是产品信息和产品的细节。我们通常只关心我们自己感兴趣的细节的细节。如果您不感兴趣，则无需检查。
设计原则：
绩效提高：
水平划分是根据某些规则将数据放在不同表中的表中，目的是解决过量量的单个表数据的问题。
分裂后，数据路由的问题已成为我们必须解决的问题。
设计原则：
绩效提高：
切割的好方法必须是较小的数据偏移量，并且可以平稳地扩展容量。
哈希是数据库中最常见的解决方案。
4.1.1误解一：数据部分倾斜问题
数据部分倾斜问题意味着我们所插入的数据不能统一散布在各种库表中。原因是库的数量和表格数量是不合时宜的。
使用哈希值来利用分区的余额和表格数，并获取库序列号和表序列号。如果您考虑一下，我们会发现以10个库和100个表为例。如果哈希值在100上超过100，则必须为10。
这将仅在0库中导致数据具有数据，并且其他库中的0表始终为空。它将导致严重的数据偏见。
基于哈希，我们不仅必须考虑库的数量和表数，而且我们需要考虑可扩展性。
误解2：扩展很难维持
我们将10个库和100个表视为总共1,000个表，获取超过1,000的哈希值，在[0，999）中获得一个数字，然后将两次划分为每个库中的每个库。表，这似乎能够解决上述问题，但是对总表数据的这种依赖将非常复杂。他们不仅必须更改算法，还必须更改数据迁移。
4.1.2积极解决方案计划1：标准辅助分片方法
错误案例II，一般思维是正确的，但是对表总数的依赖性也很依赖，我们可以根据分布序列号调整数据库序列号和表序列号的逻辑，我们可以实现标准的辅助shard方法。
我们可以扩大容量并将容量的能力扩大一倍（2的倍数中的2个）。我们的表序列号必须保持不变。库序列号可以在原始库中，也可以将其移至新库（原始库序列号以及原始库号），完全符合我们需要的持久解决方案。
该计划的缺点：
方案2：基因定律
造成不合理情况的主要原因是因为在库序列号和表序列号的计算逻辑中，此因素的合同数会影响库表的独立性。
这也是一种常用的解决方案。我们称之为遗传方法。即使原始表键中的某些基因（例如前四位数）也被用作库的计算因子，并且某些基因被用作表的计算因子。
使用此方案时，片段密钥的样本规则应全面，并且所选的chiplifting键合数字，库数，表数和四个变量会影响最终斜率。
该计划的缺点：
选项3：删除公共因素的数量
基于错误情况，在许多情况下，我们仍然希望相邻哈希人可以分为不同的库（计算库序列号与具有哈希值的库数平衡）。
为了达到这一需求，我们可以找到一种消除公共因素影响的方法。
该方案的特征是必须维护库的序列编号。
选项4：关系表冗余法
我们可以通过“路由关系表”构建芯片密钥对应的库关系。
该解决方案仍然需要通过哈希算法来计算序列号，但是当计算库序列号计算时，从路由表读取数据。由于需要每个数据查询，因此需要读取路由表，因此我们需要读取路由表，因此我们需要同时维护芯片密钥和库序列号的相应关系记录，以提高性能。
selectrandomdbidx（）;该方法是生成与表键相对应的存储库号。在这里，我们可以灵活地设置它，您可以自己设置重量，并且可以通过ratever.data迁移来调整数据倾斜问题。
尽管该计划看起来很漂亮并解决了许多问题，但它也会带来新的缺点：
选项5：一致性哈希方法
一致性哈希算法是一种更受欢迎的群集数据分区算法。例如，RedisCluster是通过一致性哈希算法的16384虚拟插槽节点的管理。
常规一致性哈希算法将引入虚拟节点，每个虚拟节点将指向一个真实的物理节点。在此方式，当添加新节点时，可以有一个解决方案来确保每个节点迁移的数据级别和迁移后每个节点的压力几乎相等。
但是，对于数据库，很少出现数据库，并且新节点不会从0的其他节点迁移，因此无需引入虚拟节点以提高复杂性。
为什么不需要使用过多的虚拟节点？
范围方法是根据数据范围将数据的存储位置划分。
最经典的数据按年度和月份分为数据库，这相对简单且不合理。
缺点：
在拆分表之前，我们可以使用联接协会多个表来查询数据，但是两个表可能不在拆分表之后的数据库中。
解决方案：
对于使用SQL时的订单，限制和其他关键字等关键字，您需要特殊处理。
解决方案：
在每件上执行相应的功能，然后总结每个碎片的结果以再次计算。
当我们使用MySQL数据库时，单个库和单个表可以将自我提示ID用作主要键。拆分表分开后，它将不起作用，并且ID将重复。
分布式ID解决方案：
分支库无法避免分布式交易
解决方案：
两个阶段提交，三个阶段提交，基于可靠消息（MQ）的解决方案，灵活的事务等。
在子饰面表之后，您将面对来自多个库或多个表的数据
解决方案：
客户适应和代理层的适应。
换句话说，我们必须使用分支表的工具来帮助我们路由到相应的库表。