企业官网建设流程全解析

1、为什么要分库分表？

随着业务的不断发展，系统数据量不断增加，即便正确设置了索引，仍然无法掩盖因为数据量过大从而导致的数据库性能下降的事实。对于单台 MySQL 服务器来说，硬件资源（如存储容量、连接数与处理能力）是有限的。当数据量过大或读写操作并发过高时，超出了单服务器的性能瓶颈，可能会对系统的稳定性产生严重隐患，甚或导致系统整体不可用。

在仅查询请求量增加的场景中，通过主从架构实现读写分离能够满足业务读多写少的需求，从而保证系统的可靠性。然而，当数据库中单表数据量增大时，业务操作的耗时会增加。有时，由于业务特点的限制，归档或删除操作无法从根本上解决问题。此外，进行大表结构变更时需要拷贝数据，若表数据量过大会导致无剩余空间进行表结构修改。

当单表数据量过大或写操作负荷过高，以至于达到存储或性能的上限时，必须通过数据切分等方式进行治理。核心思想是通过分割数据，确保单表和单机的负荷在机器性能许可的范围内。

2、切分方案有哪些？

2.1 分库

分库，指的是将数据从单个数据库拆分成多个数据库的过程。拆分后的数据库往往部署在多套集群中，这也就意味着降低了单个集群的负载压力，提升整体的读写性能。

分库通常有两种方式，垂直分库和水平分库。

2.1.1 垂直分库

垂直分库是指根据业务领域划分，将不同领域的库表拆分到多个数据库中，从而分散数据存储和读取压力，降低数据层面的耦合度。

2.1.2 水平分库

水平分库通常与分表操作一起进行。当单表数据量过大，导致存储容量和读写性能出现瓶颈时，可以根据一定规则将单表拆分成多个表，并将这些表存储在不同的数据库中，从而解决存储容量和性能问题。

2.2 分表

分表，指的是将单张数据表拆分成多张表的过程，以减少单表容量，提升读写效率。如提升数据写入时索引的构建效率、减少锁范围等；对于读流量也能较好减少耗时。

分表通常有两种方式：垂直分表和水平分表。

2.2.1 垂直分表

垂直分表是指根据实际应用场景，将数据表中的部分列拆分出来，改变原有表结构。通常可以结合实际查询需求、冷热数据分离和大字段独立存储等方式进行分表。如将db库中的订单表拆分为订单基本信息表和订单详细信息表。

2.2.2 水平分表

水平分表是指当单表数据量过大且不断增长，导致存储备份缓慢和读取效率低下时，将单表按一定规则拆分成多张表。这样可以降低单表容量，提升数据查询效率。如将db库中的订单表拆分为32个分表，order_[0-31]，分表还位于同一个库中。

2.3 分库分表

在处理海量数据时，单一的数据库和数据表会面临存储容量和性能瓶颈。通过同时进行分库和分表，我们可以将单表的数据水平拆分为多个表，并将这些表分散存储在多个数据库中。这样不仅能有效降低单一数据库和数据表的负载压力，还能提升数据的读写性能和系统的整体稳定性。

3、数据水平分片方法

确定了分库分表后就需要考虑如何将数据分到哪个库或哪个表中。分片是一种水平切分数据表的方式，可以将数据按特定策略切分成多个数据文件，这些文件既可以存储在单节点上，也可以存储在分布式的多个节点上，从而实现更强大的存储和计算能力。下面介绍几种常见的数据分片方法。

3.1 Hash分片

Hash分片，就是按照数据记录中指定关键字的Hash值将数据记录映射到不同的分片中。如图所示，通过一个Hash函数计算用户ID的Hash值而后取模，分配到对应的分片。模为4的原因是系统一共有四个节点，每个节点作为一个分片。

优点：这种方法实现简洁，可以保证数据非常均匀地分布到多个分片上。
缺点：直接用节点数作为模，如果系统节点数量变动，模也随之改变，数据就要重新Hash计算，从而带来大规模的数据迁移。显然，这种方式的扩展性不好。

必须找一个方法提升系统的扩展性，就是接下来要介绍的一致性Hash。

3.2 一致性Hash分片

一致性哈希是一种特殊的哈希算法，其核心思想是在一个虚拟的环上分布数据和节点，不同于传统的哈希算法，这种方法在增加或删除节点时能够最小化数据重分布。

如图所示，首先会引入虚拟节点，每个虚拟节点就是一个分片。这个案例中将分片数量设定为16。（因为分片数量决定了集群的最大规模，所以实践中它通常会远大于初始集群节点数。）

16个分片构成了整个Hash空间，数据记录都要通过Hash函数映射到这个空间，我们换一种方式画图，可以看得更清楚些。如下图所示，Hash空间构成了一个Hash环，数据按照顺时针找到最近的节点。

当我们新增一台服务器，即节点E时，受影响的数据仅仅是新服务器到其环空间中前一台服务器（即沿着逆时针方向的第一台服务器）之间数据。结合我们的示例，只有小红分享的消息从节点B被移动到节点E，其他节点的数据保持不变。此后，节点B只存储Hash值6和7的消息，节点E存储Hash值4和5的消息。

一致性哈希优点：

• 数据均衡：能够将数据均衡地分布到多个表中，避免某些表过度负载。
• 扩展性强：当需要增加新的表时，一致性哈希允许新的表平滑地加入系统，不会导致大量数据重新分布。部分表失效或移除的情况下，一致性哈希能将其数据分布到剩余的表中，减小影响范围。

3.3 Range分片

范围分片是一种根据数据值的范围将数据拆分成多个部分（片）的分片方法。每个片包含一个特定范围内的连续数据。通常，这种方法使用数据的某个关键字段来确定数据的范围，例如日期、用户ID、订单号等。

假设有一个订单表 orders，我们可以按订单日期将其拆分成不同的分片：

orders_2020: 存储2020年的订单
orders_2021: 存储2021年的订单
orders_2022: 存储2022年的订单

这种方式使用偏少，先介绍到这。工作中MySQL分片最常用的还是Hash分片。

4、分库分表的挑战

4.1 分布式id

在分库分表后，我们不能再使用mysql的自增主键。因为在插入记录的时候，不同的库生成的记录的自增id会出现冲突。因此需要有一个全局的id生成器。

4.2 分布式事务

原本采用单库，通过本地事务就可以保障一致性。分库后因为涉及到了同时更新多个数据库，如何保证要么同时成功，要么同时失败。分布式事务是分库分表绕不过去的一个坎。柔性事务是目前比较主流的方案，柔性事务包括：最大努力通知型、可靠消息最终一致性方案以及TCC两阶段提交等。

4.3 动态扩容

动态扩容指的是增加分库分表的数量。例如原来的user表拆分到2个库的4张表上。现在我们希望将分库的数量变为4个，分表的数量变为8个。这种情况下一般要伴随着数据迁移。

4.4 跨库关联问题

单库下的表连接操作，在分库后需要进行改造。常见的方式有冗余存储数据、应用层拼接等；

4.5 服务、数据平滑迁移

单库单表迁移到分库分表后，为了保证平稳过渡，上层无影响，需要采用相应的策略进行服务、数据的迁移；

4.6 数据库基本的增删改功能

对于开发人员而言，虽然分库分表，但还是希望能和单库单表那样的去简单地操作数据库，包括查询与DML操作。（通常是通过数据库中间件实现，中间件的原理大体分为：数据源代理、数据库代理。具体可搜索cobar、zebra、sharding-jdbc等关键字了解其原理）

4.7 子表分库分表

在进行主表分库分表时，子表也需要进行相应的处理。需要按照相同的分片规则进行分库分表，确保数据的关联性和查询的效率。工作量会翻倍。

5、项目实战

实践中的大表治理阈值是：单表数据量不超过两千万条，同时还需要综合考虑索引量和单行容量——如果单行数据量大或索引数量多，阈值应该更低。超过这个阈值后，查询性能下降、DDL 耗时剧增、备份恢复变慢等问题会集中爆发，迁移的难度和风险也会成倍增加。

但分片设计只是第一步，真正棘手的是迁移过程。线上服务 7×24 小时运行，不可能停机切库；亿级数据搬迁过程中新的写入还在不断发生；切流过程中一旦发现数据不一致，需要能够回滚。整个过程就像是"边开飞机边换引擎"——流量在线上跑着，任何操作失误都可能导致线上故障。更棘手的是，数据迁移和业务强绑定、侵入业务逻辑，很难做到一套方案通用复用。这些问题如果处理不当，轻则数据丢失，重则系统整体不可用。

本节结合多个大表治理项目的实战经验，给出一套通用的不停机迁移方案。核心目标是：平滑迁移 + 数据一致性保障 + 操作可回滚。

5.1 容量规划

容量规划是分库分表设计中容易被忽视但至关重要的环节。分片数量一旦确定并写入数据，后续扩容（如从 16 库扩到 32 库）需要重新 rehash 和数据迁移，成本极高。因此，在拆分设计阶段必须充分评估当前和未来的容量需求，留足扩展空间。

数据量评估。首先需要摸清待拆分表的现状和增长趋势。关键指标包括：当前数据行数、单行平均字节数、当前总数据量（行数 × 单行字节数）、日均增长行数、月均增长数据量。基于这些指标，推算未来 2~3 年的数据量。例如，当前 5000 万行、日均增长 20 万行，三年后将达到约 2.7 亿行。数据量评估不仅看行数，还要考虑单行大小——如果表中有 TEXT/BLOB 等大字段，实际存储占用可能远大于行数 × 固定字节数的估算。

分片数量计算。分片数量需要同时满足两个约束：单分片数据量不超过治理阈值（如两千万行），以及总分片数能覆盖未来 2~3 年的增长。计算公式很简单：分片数 = 预期总数据量 / 单分片阈值。以上面的例子为例，2.7 亿行 / 2000 万行 = 13.5，向上取 2 的幂次得到 16。实践中建议分片数取 2 的幂次（如 8、16、32、64），这样取模路由的扩容可以按倍数翻倍，减少 rehash 的工作量。同时要预留 30%~50% 的缓冲空间——不要把分片设计得刚好够用，留有余地才能从容应对业务增长超预期的情况。

硬件资源规划。分库分表后，数据库实例数量成倍增加，需要提前规划硬件资源。核心考虑点包括：每个分片数据库实例的规格（CPU、内存、磁盘），通常单分片配置不低于原单库配置的 1/N（N 为分片数），但要保证单分片能独立承受其分片的读写压力；磁盘空间需要预留数据量 2~3 倍的余量，考虑索引、临时表、binlog 等开销；如果使用云数据库，还需要考虑实例规格的可选档位和升级路径。

连接池规划。双写阶段是连接数压力最大的时期——应用同时连接老库和所有新库分片，数据库连接数翻倍。假设原连接池大小为 20，分 16 个库，双写期间连接数可能从 20 增长到 20 + 16×20 = 340。需要提前评估数据库最大连接数配置（MySQL 默认 151，通常需要调大到 500~1000），同时合理设置应用侧连接池上限，避免连接耗尽。建议在双写阶段适当调小单分片连接池大小（如从 20 降到 10），用较小的连接池配合排队机制度过双写期。

性能预算。迁移过程中引入了额外开销，需要为每个环节预留性能预算。双写阶段：每次写入操作从 1 次 DB 调用变为 2 次，写 RT 预估增加 50%~100%（取决于新库网络延迟）；灰度切读阶段：部分读流量走新库，需要监控新库的查询 RT 是否达标；数据校验阶段：校验任务会消耗数据库 CPU 和 IO，建议在低峰期执行或限制并发度。整体性能预算建议：双写期间写 RT 不超过原来的 2 倍，切读完成后新库读 RT 不超过老库的 1.5 倍。如果超出预算，需要排查新库索引是否完备、分片键是否均匀、是否存在跨分片查询。

迁移带宽评估。全量数据迁移阶段会产生大量网络流量，需要评估迁移带宽是否充足。计算方式：总数据量 / 期望迁移时间 = 所需带宽。例如，500GB 数据期望 4 小时迁完，需要约 35MB/s 的带宽。如果带宽不足，可以考虑分批迁移、压缩传输等方式。增量同步阶段虽然流量较小，但需要持续占用带宽，需确保不影响正常业务流量。

5.2 迁移整体流程与阶段拆解

整套迁移方案分为九个阶段，覆盖从前期梳理到最终收尾的完整生命周期。每个阶段的读写策略、具体事项和回滚方案如下表所示：

数据迁移工具：负责在新老库之间同步数据，支持全量同步和增量同步两种模式。全量同步将老库的存量数据批量导入新库，增量同步则通过解析数据库日志（如 MySQL binlog）实时追平老库的变更。开源方案有 DataX、Canal 等，各云厂商也提供类似的数据传输服务。选型时需关注：是否支持分库分表路由（能根据分片键将数据写到对应的分表）、增量同步延迟、断点续传能力。数据迁移工具同时提供数据校验服务，可以在平台上进行实时数据校验。

数据一致性校验工具：负责比对新老库的数据差异。工具定期扫描两个库中相同范围的数据，逐行比较字段值，输出不一致的记录列表。开源方案有 pt-table-checksum 等，也可以基于业务自研。选型时需关注：比对效率（百万级数据应在 10 分钟内完成）、是否支持分片表比对、比对结果能否直接驱动补偿。

5.2.1迁移准备

迁移的第一步不是动手搬数据，而是全面梳理。这个阶段需要完成四项工作：整理需要迁移的表清单，明确哪些表需要拆分、哪些不需要；梳理所有访问迁移表的代码，包括 DAO 层、Service 层以及跨服务的调用链路；梳理迁移表的上下游依赖，包括下游订阅（如 binlog 订阅、消息队列消费）和数据校验任务等；梳理数仓任务，确认离线数仓是否依赖该表的同步链路。这些梳理工作决定了后续改造的范围和风险面，必须做到不遗漏。

5.2.2业务改造上线

梳理完成后，进行业务侧的代码改造并上线。改造内容包括两个层面：数据源代码改造——为分库分表准备新的数据源配置和分片 Mapper，确保应用能够连接新的分片库并正确路由；灰度读和双写控制改造——在应用中嵌入灰度读路由逻辑和双写拦截器，通过动态配置开关控制，此时开关全部关闭，线上行为与改造前完全一致。改造上线后系统具备双写和灰度读的能力，但尚未实际启用。后续会讲解双写控制方案

5.2.3存量数据同步

业务改造上线完成后，启动数据迁移任务。迁移工具首先进行全量数据迁移，将老库的存量数据批量导入新的分库分表。全量同步完成后自动切换到增量同步模式，通过解析老库的 binlog 实时拉取增量变更并回放到新库。整个同步过程是"旁路"进行的，老库的正常读写不受影响。当增量同步延迟降到秒级以内时，可以认为增量同步已追上源库，存量数据就绪。

这个阶段需要关注同步延迟和断点续传能力。如果同步延迟持续较大，需要排查迁移工具的吞吐瓶颈（如并发度、批量大小配置）或网络带宽限制。迁移工具应支持断点续传，避免因任务异常中断而从头开始。

5.2.4数据校验与读切换测试

增量同步追上源库后，进入第一轮数据校验。使用数据一致性校验工具对新老库的数据进行全量比对，确认存量数据和增量数据在新库中的一致性。校验通过后，开始读切换测试——将少量读流量切到新库，验证新库的查询结果和性能是否正常。

读切换测试采用逐步放量的策略：先按千分比例切换，观察新库查询耗时、错误率等指标；确认无异常后逐步扩大读比例，直至全部读流量走新库。整个测试过程中，写流量始终走老库，数据迁移工具的增量同步保持运行，新库数据持续追平。

读切换测试成功后，将读策略回滚至老库，为下一阶段开启双写做准备。这一步看似多余——既然测试成功了为什么不直接保持读新库？原因是：这一步核心目的是验证新库读能力，防止最后切读时暴露新库读能力有问题导致前功尽弃。同时读切换测试期间老库仍然是写入主库，新库的数据通过迁移工具同步，存在秒级延迟。如果此时直接开启双写（应用层同步写新老库），与迁移工具的增量同步会产生重复写入冲突。因此需要先回滚读策略、暂停迁移工具同步，再开启双写，确保数据写入链路清晰无冲突。

5.2.5开启双写

读切换测试成功并回滚读策略后，开启双写。操作步骤是：先暂停数据迁移工具的增量同步任务，再通过动态配置中心开启双写开关。双写开启后，应用层的每次写操作（INSERT/UPDATE/DELETE）会同时写入老库和新库，读流量暂时仍走老库。

选择在 DAO 层而非 Service 层做双写，有几个明显优势：对上层业务代码零侵入，Service 层无需任何改动；双写逻辑集中在一个插件中，便于维护和排查；可以精确控制哪些表需要双写，通过白名单机制实现细粒度管理；如果双写出现问题，只需关闭开关即可回退到只写老库的状态，影响范围可控。

双写插件采用"三态切换"设计，通过动态配置中心控制，无需重启服务。三种模式对应迁移的不同阶段：

模式一（双写-老库为主）：先写老库成功后再写新库，新库失败仅告警。对应阶段 5~7，老库仍是数据权威来源。

模式二（双写-新库为主）：先写新库成功后再写老库，老库失败仅告警。作为切写时的可选中间态，新库成为数据权威来源。

模式三（关闭双写）：直接走原有流程。对应阶段 8，迁移完成后或紧急回滚时使用。

三态切换的设计本质是在可用性（Availability）和一致性（Consistency）之间做平衡。双写要做到强一致，需要同步等待两个库都写入成功才返回，但这会牺牲在线业务的 RT——大多数业务无法接受写耗时翻倍。因此实践中普遍采用"尽力而为"的策略：主库写入成功即返回，辅库异步写入，失败只告警不阻塞。这种设计牺牲了强一致性，但保证了可用性，不一致问题交给后续的数据校验和补偿机制来兜底。在迁移场景下，可用性优先于一致性是更务实的选择——数据不一致可以修复，但服务不可用的代价要大得多。

5.2.6双写期间数据校验

双写运行一段时间后，进行第二轮数据校验。这一轮校验的目标是发现双写过程中可能产生的不一致数据。校验方式与第一轮相同：使用数据一致性校验工具定时比对新老库的数据差异，同时在数据迁移工具平台上进行实时数据校验。

校验过程中如果发现不一致，需要分析原因。常见原因包括：双写过程中新库写入失败但未及时告警、迁移工具暂停期间的增量数据未完全追平、分片键为空导致路由失败等。对于不一致的数据，通过泛化调用或批量修复脚本，将老库中存在但新库中缺失的数据重新写入新库。校验和补偿应该在开启双写后、读流量切换前完成，确保新库数据完全可信。

除了实时校验，还需要建立定时的全量数据校验机制。校验频率建议在迁移初期设置较高（如每小时一次），稳定后逐步降低。双写期间的新老库数据比对应贯穿整个双写周期，不是一次性工作。

5.2.7读流量切换

第二轮数据校验成功后，手动触发读流量切换。这次是真正的读切换，不是测试——读流量将永久切到新库。切换采用灰度策略，基于分片键（如 userId）取模实现，动态配置中心维护一个灰度比例值，应用层在读取时判断是否命中灰度：

/** * 灰度路由判断（千分比） */publicbooleanshouldReadFromShard(LonguserId){intgrayPermille=configCenter.getGrayReadPermille();// 0~1000if(grayPermille<=0)returnfalse;if(grayPermille>=1000)returntrue;returnMath.abs(userId.hashCode())%1000<grayPermille;

灰度过程遵循"千分比 → 百分比 → 全量"的阶梯逐步推进，每一步观察新库的查询耗时、错误率、数据一致性指标。灰度切读期间双写保持开启，如果新库读取发现问题，将灰度比例调回 0 即可立即回退，因为老库的数据始终在双写中被更新。

当读流量完全切换到新库并稳定运行后，进入读写平稳状态——读走新库，写双写新老库，数据迁移工具已暂停。此时可以停止迁移任务，进入下一阶段。

5.2.8停止同步与双写

读写平稳后，停止数据迁移任务，关闭数据同步。然后停止双写，此时读写均在新库完成。这一步标志着迁移的核心工作完成。

停止双写有两种策略：直接关闭双写（模式三），读写全部走新库；或先切换为"新库为主"双写（模式二），观察一段时间后再关闭双写。后者更为保守，适合对数据一致性要求极高的场景。

这一阶段的回滚需要特别注意：停止双写后老库不再更新，如果需要回滚到老库，属于"有损回滚"——需要通过数据补偿工具将新库的增量数据回写到老库。因此建议在停止双写后保留老库一段时间（如一周），作为最终的数据兜底，确认无误后再彻底下线。

5.2.9收尾

迁移完成后，通知下游依赖老库相关资源进行切换。这包括：将下游的 binlog 订阅、消息队列消费等切到新库；将数仓任务的同步链路从老库切换到新库。这些收尾工作确保所有依赖链路都已指向新库，老库可以安全下线。

5.3基于 MyBatis 拦截器的双写插件

这部分留给读者自己研究，或者联系博主进行咨询。

5.4数据一致性保障

双写机制虽然保证了写入的"双份"，但并不能完全保证数据一致性。以下几个场景可能导致不一致，需要额外的保障机制。

双写失败导致的不一致。当主库写入成功、辅库写入失败时数据就会出现不一致。插件的处理策略是辅库失败只告警不阻塞，保证主库写入不受影响，但这意味着需要人工介入修复。实践建议：为双写失败配置告警（如日志关键词监控、告警群通知），发现失败后及时排查。如果失败率持续偏高，应考虑关闭双写回退到单写老库状态。

迁移工具暂停期间的增量数据。开启双写前需要暂停数据迁移工具的增量同步任务，暂停期间的秒级增量数据不会被自动同步到新库。这部分数据需要通过数据校验发现并补偿——通过泛化调用或批量修复脚本，将老库中存在但新库中缺失的数据重新写入新库。校验和补偿应该在开启双写后、读流量切换前完成。

分片键为空。分库分表要求数据必须携带分片键才能正确路由。如果历史代码中某些写入路径未设置分片键，双写时新库写入会失败。双写插件在写入前进行前置校验，分片键为空时抛出异常。建议在双写开启前全面排查所有写入路径，确保分片键不会为空。

数据校验贯穿始终。从存量同步追上源库后的第一轮校验，到双写期间的第二轮校验，再到灰度切读过程中的持续比对，数据校验是贯穿迁移全过程的活动，而非某个阶段的独立工作。实时告警 + 定时全量校验 + 人工抽检，三层保障确保数据一致性。校验频率建议在迁移初期设置较高（如每小时一次），稳定后逐步降低。

写作不易，您的鼓励是我不断输出优质文章的动力，欢迎评论、转发、收藏。抱拳。