一、什么时候要分库分表数据量级达标业务数据快速增长单表数据量达到1000万行或20GB阈值。常规优化失效已尝试主从读写分离、索引优化等手段但仍无法解决性能瓶颈。资源达到瓶颈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变更如加字段需要执行多次。