企业官网建设流程全解析

一、什么时候要分库分表

1. 数据量级达标：业务数据快速增长，单表数据量达到1000万行或20GB阈值。

2. 常规优化失效：已尝试主从读写分离、索引优化等手段，但仍无法解决性能瓶颈。

3. 资源达到瓶颈：

   • IO瓶颈：磁盘IO或网络IO达到上限。

   • CPU瓶颈：因聚合查询频繁或数据库连接数过多导致CPU负载过高。

二、分库分表的拆分策略

1、垂直拆分

垂直分库：

定义：按照业务功能将不同的表拆分到不同的数据库中。

核心逻辑：专库专用。原本一个电商数据库里有用户表、订单表、商品表。现在拆分成三个独立的数据库：用户库、订单库、商品库。

优点：

• 业务解耦：不同业务线互不影响，某个库宕机不会导致全站瘫痪。

• 分担压力：不同库可以部署在不同的服务器上，分担了单台服务器的CPU、IO和连接数压力。

• 便于扩展：针对高并发的业务（如订单），可以单独增加订单库的服务器配置

缺点：

• 分布式事务：跨库操作（如扣库存+生成订单）变得复杂，需要引入分布式事务（如Seata）。

• 跨库Join：原本一条SQL能关联查询的数据，现在需要在应用层组装或通过微服务接口调用。

• 运维成本：数据库实例增多，运维复杂度上升。

垂直分表：

定义：按照字段（列）的活跃度或大小，将一张宽表拆分成多张表。

核心逻辑：将不常用、大字段（如Text、Blob）拆分到扩展表中，主表只保留常用、查询频率高的字段。

优点：

• 提升查询效率：单表数据量不变（行数不变），但单行数据变小，一个数据页能存更多行，减少了磁盘IO，内存命中率更高。

• 避免跨页：避免因大字段导致行溢出，影响主键索引效率。

缺点：

• 需要关联查询：查完整信息需要Join两张表。

• 事务一致性：插入数据时需要同时向两张表插入，需保证事务。

2、水平拆分

水平分库：

定义：将同一个表的数据，按照某种规则（如ID取模、时间范围）拆分到多个数据库中。

核心逻辑：每个数据库的表结构完全相同，只是存储的数据不同。解决单表数据量过大的问题。比如有1亿用户，拆成4个库，每个库存2500万。

优点：

• 解决海量数据存储：单库容量有上限，水平分库理论上可以无限扩展存储。

• 大幅提升并发：请求被打散到多个数据库实例，极大提升了系统的吞吐量。

缺点：

• 数据路由复杂：需要中间件（如ShardingSphere）或应用层代码来计算数据落在哪个库。

• 全局ID问题：不能再用单库自增ID，需要分布式ID生成器（如雪花算法）。

• 扩容困难：如果需要增加数据库节点，历史数据需要重新迁移（通常用一致性Hash解决）。

水平分表：

定义：在同一个数据库内，按照某种规则（如ID取模、时间范围）将一张数据量巨大的表拆分成多张表结构完全相同的小表。

核心逻辑：解决单表数据量过大导致的查询性能下降问题。比如一张订单表有1亿条数据，拆分成order_0、order_1、order_2、order_3四张表，每张表存储2500万条数据。

优点：

• 提升查询效率：单表数据量变小，B+树索引层级变浅，磁盘IO减少，查询速度显著提升。

• 实现相对简单：相比水平分库，不需要考虑跨库网络通信、分布式事务等复杂问题，只需在应用层做SQL路由即可。

• 成本低：不需要额外购买数据库服务器，只需在现有数据库实例中建多张表

缺点：

• 无法分担服务器压力：所有表仍在同一个数据库实例中，CPU、内存、磁盘IO、网络IO瓶颈依然存在。这是水平分表与水平分库最本质的区别。

• 单库容量仍有上限：受限于单台服务器的磁盘容量，数据总量无法无限扩展。

• 全局ID问题：不能再用单表自增ID，需要分布式ID生成器（如雪花算法）。

• 跨表查询复杂：原本一条SQL能查全量数据，现在需要在应用层做聚合（如分页、排序、统计）。

• 运维成本增加：表数量增多，DDL变更（如加字段）需要执行多次。