分库分表原理如何从痛点解决到策略落地？

分库分表是数据库水平扩展（Scale-Out） 的核心技术，通过“分而治之”将单库/单表的压力分散到多个库/表，解决海量数据存储、高并发写入/查询的瓶颈，是中大型系统架构演进的关键环节。 一、核心痛点：为什么必须分库分表？ 单库单表在数据量和并发量达到阈值后，会出现明显性能瓶颈，主要体现在4个方面： 数据量过大：单表超千万/亿级时，索引失效、查询变慢、备份恢复耗时久（如100GB单表mysqldump需数小时）。 并发压力高：单机数据库连接数、CPU、IO资源有限，QPS/TPS突破上限（如MySQL默认最大连接数仅151）。 存储受限：单机磁盘容量无法支撑TB级数据，扩容需升级硬件（成本高、扩展性差）。 业务耦合：多业务模块共用一个库，相互影响，故障易扩散（如订单库异常导致用户库不可用）。 二、核心拆分方式：垂直切分 vs 水平切分 分库分表本质是垂直切分（按业务/字段） 和水平切分（按数据行） 的组合，两者解决的问题不同，需根据场景选择。 1. 垂直切分：按“维度”拆分，解耦业务/字段 （1）垂直分库：按业务模块拆分，隔离压力 原理：将不同业务的表分散到独立数据库（如用户库、订单库、商品库），每个库只负责一类业务。 场景：系统初期业务耦合、多模块并发冲突，需解耦时。 优点：业务隔离、故障可控、扩展灵活，适配微服务架构。 缺点：不解决单表数据量问题，跨库JOIN复杂。 示例：电商系统将user（用户表）、order（订单表）、product（商品表）分别部署在3个独立数据库。 （2）垂直分表：按字段相关性拆分，简化单表 原理：将单表中“高频字段”和“低频/大字段”拆分（如基本信息+详情信息），减少单表数据量和IO。 场景：单表字段多、大字段（如文本、图片）占比高，高频查询仅需部分字段。 优点：查询效率提升（无需加载无用字段）、单表体积减小。 缺点：需通过关联查询恢复全量数据，增加开发成本。 示例：用户表拆分为user_base（id、name、phone）和user_ext（id、address、avatar、备注），登录时仅查user_base。 2. 水平切分：按“数据行”拆分，分摊压力 （1）水平分表：单库内拆多表，减小单表体积 原理：在同一个数据库内，将单表按规则拆分为多个子表（如order_0、order_1…order_n），每个表存储部分数据。 场景：单表数据量过大，但数据库并发压力尚可，需提升查询效率。 优点：单表数据量小，索引查询快、维护简单。 缺点：数据库实例未扩容，并发瓶颈仍存在。 （2）水平分库：多库部署拆表，提升并发能力 原理：将水平分表的数据进一步分散到多个数据库实例（如db_0存order_0、db_1存order_1），物理隔离压力。 场景：单库并发过高、QPS/TPS突破上限，需线性扩展并发能力。 优点：并发能力随库数量线性提升、负载均衡、存储无上限。 缺点：架构复杂，跨库查询、事务、ID生成等问题突出。 三、核心分片策略：如何拆分数据？ 水平切分的关键是分片规则，需根据业务场景选择，确保数据均匀分布、查询高效。 分片策略 原理 优点 缺点 适用场景 哈希取模 对分片键（如user_id、order_id）哈希后取模，分配到对应库/表 数据均匀、负载均衡、扩容方便（增库改模数） 扩容需全量数据迁移 用户中心、订单中心（数据均匀需求） 范围分片 按分片键的范围（如时间、ID区间）拆分（如2024年数据→表1，2025年→表2） 分区明确、查询高效（按范围查无需遍历所有表） 易产生热点（如近期数据）、扩容需调整区间 日志表、订单表（按时间查询） 一致性哈希 哈希环映射，数据迁移量小（仅相邻节点调整） 扩容缩容影响小、数据分布均匀 实现复杂、需额外维护 缓存分片、动态扩容场景 地域/业务分片 按地域（如华北/华南）、业务线拆分 隔离性强、符合业务逻辑 扩展不灵活、易产生热点 多地域部署、多业务线系统 示例（哈希取模）：订单表按order_id % 4拆分，order_id=101→order_1，order_id=102→order_2，均匀分布到4张表。 四、核心实现方案：如何落地？ 分库分表落地需解决路由、读写分离、分布式事务、全局ID四大核心问题，主流实现方式有2种： 1. 客户端分片（Sharding-JDBC） 原理：以Jar包形式嵌入应用代码，拦截SQL、解析路由、执行并聚合结果，无中间件依赖。 优点：轻量、无网络开销、性能高、开源免费（如ShardingSphere）。 缺点：与应用耦合、多语言支持差、运维需适配每个服务。 适用：中小型系统、技术栈统一（如Java）、追求高性能。