MySQL千万级分库分表：原理、分片设计、实战与避坑方案

学者猫头鹰
0 阅读26分钟

本文面向分库分表入门学习者，系统梳理千万级MySQL海量数据的完整扩容解决方案，覆盖业务痛点、前置优化原则、核心原理、分片设计、中间件选型、实战配置、生产难题、零停机数据迁移、运维监控、落地规范与面试核心考点。全文兼顾理论知识、代码实战、线上落地与面试备考，可直接作为学习手册、项目架构方案与求职面试资料。

核心设计思想：分库分表是MySQL数据扩容的最后手段而非首选方案，坚决拒绝过早分片、过度设计，严格遵循阶梯式优化的架构准则。

一、业务痛点与前置优化原则

1.1 千万级单表核心痛点

当MySQL单表数据量突破千万级别，传统数据库优化手段触顶，衍生索引、运维、性能、扩容四大核心问题，严重制约业务迭代：

  • 索引性能衰退：B+树索引层级加深、索引文件体积膨胀，磁盘IO次数大幅增加，普通查询、范围查询响应耗时翻倍，高频接口性能显著下降。

  • DDL运维风险极高：大表执行加字段、改字段、新增索引等DDL操作会触发长时间锁表，阻塞线上读写请求，直接影响业务可用性，极易引发生产事故。

  • 单库性能瓶颈：单数据库实例存在连接数、CPU、内存、磁盘IO硬性上限，高并发场景下易出现连接打满、IO阻塞、线程池耗尽等问题，无法支撑流量持续增长。

  • 无法水平扩展：单库单表架构读写能力固化，无法通过新增服务器、集群节点实现性能扩容，业务增长遇到无法突破的硬件瓶颈。

1.2 常规优化手段的极限瓶颈

索引优化、读写分离、冷热数据分离是中小数据量主流优化方案，但数据量达到千万级后，所有低成本优化方案均会触达性能上限：

  • 索引优化：完成最优索引设计后，无法突破大数据量检索极限，复杂多条件查询、模糊查询、聚合查询依然存在严重性能问题。

  • 读写分离：仅能分摊读请求压力，完全无法解决单表存储上限、写压力集中、热点数据瓶颈，核心写操作依然全部堆积在主库。

  • 冷热数据分离：可归档历史冷数据释放存储压力，但若业务持续产生新增热数据，热数据会快速累积，短期内再次触发性能瓶颈。

1.3 阶梯式架构优化前置原则（重中之重）

数据库优化必须遵循由简到繁、低成本优先的阶梯顺序，禁止直接落地分库分表，杜绝过度设计与无效开发：

索引优化 → 读写分离部署 → 冷热数据归档 → 最终评估分库分表

仅当以上所有低成本优化方案全部失效，且业务数据量、并发量持续上涨、无任何缓解空间时，才可启动分库分表架构改造。

二、分库分表核心概念

分库分表是海量数据水平扩容的核心方案，整体分为垂直拆分和水平拆分两大类。其中垂直拆分侧重业务解耦与结构优化，水平拆分侧重海量数据拆分，是千万/亿级数据扩容的核心手段。

2.1 垂直拆分

垂直拆分核心是按业务维度、字段属性拆分资源，不改变单表数据量，主要解决业务耦合、表结构臃肿、冷热字段混杂问题。

2.1.1 垂直分库（按业务模块拆库）

将单一聚合业务大库，按照微服务业务边界，拆分为多个独立数据库，实现业务解耦与资源隔离。

  • 示例：统一业务大库 → 拆分出订单库、商品库、用户库、支付库、物流库

  • 核心价值：各业务独立部署、独立扩容、独立运维，单一业务故障不会牵连整体系统，实现资源隔离与故障隔离。

2.1.2 垂直分表（按字段冷热拆表）

将字段繁多、冷热混杂的宽表，拆分为两张一一关联的独立数据表，分离高频热字段与低频冷字段，优化查询效率。

  • 示例：订单表拆分 → 订单主表（订单ID、用户ID、金额、状态等高频热字段）、订单扩展表（备注、物流详情、冗余参数等低频冷字段）

  • 核心价值：缩小单表数据宽度、精简索引体积，避免无效字段扫描，大幅提升高频业务查询性能。

2.1.3 垂直拆分适用场景

  • 数据表字段数量过多、单表宽度过大，查询效率低下；

  • 表数据冷热分层明显，部分字段访问频率极低；

  • 业务模块边界清晰，可完全解耦独立运行。

2.2 水平拆分（项目核心常用）

水平拆分核心是按固定规则拆分海量数据，所有子表结构完全一致，将单表海量数据分散至多表、多库，从根源解决单表数据量上限问题，是千万级数据扩容的核心方案。

2.2.1 水平分表

在同一个数据库实例内，将一张超大表拆分为多张结构一致的子表，数据按规则分散存储。

  • 示例：order大表 → order_0、order_1、order_2 ... order_n

  • 特点：仅解决单表数据量大问题，无法突破单库IO、连接数、并发瓶颈，适合单库数据量超标、并发压力较小的场景。

2.2.2 水平分库+分表

同时拆分数据库与数据表，搭建多库多表分布式架构，将海量数据分散到多个独立数据库的多张子表中。

  • 特点：既解决单表海量数据存储问题，又突破单库硬件性能瓶颈，支持无限水平扩容；

  • 适用场景：单表数据千万级以上、数据持续增长、读写并发压力大的核心交易业务（订单、支付、流水、用户行为数据）。

三、分片核心核心要素（全文重点）

3.1 分片键（Sharding Column）

分片键是分库分表的核心基石，是数据路由、分片匹配、数据分布的唯一依据，分片键的选择直接决定系统性能、数据均衡度、运维难度与后续扩展性。

3.1.1 通用分片键

企业项目中最稳定、通用的分片键：user_id、order_id

3.1.2 分片键核心选择标准

  1. 查询适配性：业务绝大多数增删改查场景必须携带分片键，最大限度规避无分片键全分片广播查询。

  2. 规避跨库查询：关联业务数据尽量落在同一分片库表，减少跨分片关联查询，降低架构复杂度。

  3. 数据均衡性：保证数据均匀分布在所有分片节点，杜绝数据倾斜、热点分片，实现流量与存储均衡分摊。

3.1.3 核心避坑点

分片键一旦确定并落地，后期无法平滑修改，重构成本等同于二次开发，是分库分表项目最大的技术债务，前期必须充分调研设计。

3.2 主流分片算法

3.2.1 哈希取模分片（Mod）—— 生产首选

通过对分片键进行取模运算，将数据均匀分配至各个分片，是互联网核心业务主流方案。

  • 优点：数据分布极度均匀，无热点分片，读写流量均衡分摊，并发性能稳定；

  • 缺点：扩容兼容性差，非倍数增减分片数会改变路由规则，需全量迁移数据，扩容成本极高；

  • 适用场景：分片数量固定、数据均匀、无需频繁扩容的核心交易、订单业务。

3.2.2 范围分片（时间/ID区间）

按照时间、自增ID等区间规则划分分片，支持按年、按月、按ID区间拆分数据。

  • 优点：扩容极其简单，新增区间分片即可，无需迁移任何历史数据；

  • 缺点：存在永久热点分片，最新业务流量、新增数据全部集中在最新分片，单分片压力过载；

  • 适用场景：时序日志、系统流水、监控数据等有序非核心业务数据。

3.2.3 复合分片与自定义分片

  • 复合分片：结合哈希+范围双重规则，兼顾数据均匀性与扩容灵活性，弥补单一算法的短板；

  • 自定义分片：基于特殊业务场景自定义路由规则，适配个性化分片需求，灵活性最高。

3.3 分布式ID配套方案

分库分表架构下，禁止使用数据库自增主键。多库多表独立自增会直接出现主键冲突，必须采用全局唯一分布式ID方案，保障全分片ID唯一、有序。

主流成熟方案及生产取舍：

  • 雪花算法（Snowflake）：业界通用首选，高性能、趋势递增、无中心化，适配绝大多数订单、交易业务；

  • UidGenerator：百度优化版雪花算法，彻底解决时钟回拨问题，稳定性更强，大厂生产核心选型；

  • Redis自增ID：实现简单、有序可控，仅适合中小流量非核心业务，高并发场景存在Redis单点性能瓶颈。

3.4 雪花算法核心隐患：时钟回拨

雪花算法高度依赖服务器时间戳，服务器NTP时间同步、手动校准时间会触发时钟回拨，导致生成重复ID，引发分片主键冲突、数据插入失败等生产问题。

核心成因：服务器自动时间同步、人工校准系统时间、NTP服务向后回拨时间。

生产解决方案：

  • 程序缓存最后一次生成ID的时间戳，实时比对检测回拨，触发回拨则阻塞等待时间追平；

  • 预留机器位、序列号做短时间回拨补偿，兜底避免重复ID；

  • 核心业务直接使用 UidGenerator 等成熟框架，从底层规避原生雪花算法缺陷。

四、分库分表中间件选型对比

4.1 Sharding-JDBC（生产首选）

  • 架构模式：客户端嵌入式分片，无独立代理服务，直接集成在应用程序中；

  • 核心优势：部署零成本、无额外网络开销、性能极高、适配SpringBoot生态、运维成本低；

  • 适用场景：Java后端项目、微服务架构、高性能核心业务，是目前行业主流方案。

4.2 Sharding-Proxy

  • 架构模式：独立服务端代理分片，统一对接数据库，提供通用访问入口；

  • 核心优势：支持多语言客户端，统一管控分片规则，适合多技术栈异构项目；

  • 缺点：增加一层网络转发，存在额外性能损耗，性能低于Sharding-JDBC。

4.3 MyCat（老牌存量方案）

  • 定位：国内早期主流代理式分片中间件，生态成熟但官方迭代放缓；

  • 现状：新项目已全面淘汰，仅老旧存量项目继续维护使用。

4.4 中间件选型结论与对比总结

所有Java SpringBoot新项目，优先选择 Sharding-JDBC，兼顾性能、易用性与生态适配性，是千万级数据扩容最优解。

中间件架构模式性能多语言支持运维成本适用场景
Sharding-JDBC客户端嵌入极高（无代理层）仅Java低Java微服务、新项目、高性能核心业务
Sharding-Proxy服务端代理中等（存在网络转发）全语言中多技术栈项目、统一分片管控
MyCat服务端代理一般全语言高老旧存量项目，新项目不推荐

五、Sharding-JDBC 实战核心要点

5.1 核心配置模块

Sharding-JDBC核心配置分为四大核心模块，所有分片业务均基于此搭建：数据源配置、分片规则配置、广播表配置、绑定表配置。

5.2 三类核心特殊表概念

5.2.1 分片表

业务核心海量数据表，严格按照分片规则分散存储在多库多表中，是分片架构的核心载体。

示例：订单表、交易流水表、用户行为记录表等大数据量表。

5.2.2 广播表

所有分片库中均存在该表，且全部分片数据完全一致，用于解决字典类数据跨分片查询问题。

示例：数据字典表、系统配置表、地区码表、常量配置表。

核心价值：避免字典数据分片分散，无需跨库查询常量数据，简化查询逻辑。

5.2.3 绑定表

分片键完全一致的关联业务表，绑定后关联数据会落在同一分片，彻底规避跨分片Join报错问题。

示例：订单主表与订单详情表，均以order_id为分片键，配置为绑定表。

5.3 标准可运行YAML配置示例

# Sharding-JDBC 核心生产配置（SpringBoot）
spring:
  shardingsphere:
    # 多数据源配置
    datasource:
      names: ds0,ds1
      ds0:
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        url: jdbc:mysql://127.0.0.1:3306/sharding_db0?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai
        username: root
        password: 123456
      ds1:
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        url: jdbc:mysql://127.0.0.1:3306/sharding_db1?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai
        username: root
        password: 123456
    # 分片规则配置
    rules:
      sharding:
        # 分片表规则
        tables:
          t_order:
            actual-data-nodes: ds->{0..1}.t_order_->{0..1}
            database-strategy:
              standard:
                sharding-column: user_id
                sharding-algorithm-name: database-mod
            table-strategy:
              standard:
                sharding-column: order_id
                sharding-algorithm-name: table-mod
        # 分片算法绑定
        sharding-algorithms:
          database-mod:
            type: MOD
            props:
              sharding-count: 2
          table-mod:
            type: MOD
            props:
              sharding-count: 2
        # 绑定表配置（杜绝跨库join）
        binding-tables:
          - t_order,t_order_item
        # 广播表配置（全局一致字典表）
        broadcast-tables:
          - t_dict,t_config
    # 开启SQL日志打印（调试必备）
    props:
      sql-show: true

六、分片底层原理、经典难题与生产解决方案

6.0 Sharding-JDBC 完整底层执行链路

分片并非简单的数据拆分，拥有标准化的完整执行链路，是理解分片核心原理的关键：SQL解析 → 分片路由 → SQL改写 → 多分片并行执行 → 结果聚合排序

  • SQL解析：解析用户SQL语句，识别查询字段、查询条件、分片键、聚合函数与排序规则；

  • 分片路由：根据分片键+自定义分片算法，精准定位执行库表，无分片键则触发全分片广播；

  • SQL改写：自动替换真实物理表名、补充分片条件，生成适配各分片的可执行SQL；

  • 分片执行：多线程并行执行多分片SQL，提升批量查询执行效率；

  • 结果聚合：合并所有分片返回数据，统一全局排序、分页、聚合，返回最终结果。

6.1 分片架构核心取舍（Trade-off）

分库分表是以复杂度换性能的架构方案，存在明确的利弊取舍，架构设计必须清晰认知：

  • 核心收益：突破单库单表存储、IO、并发上限，支持海量数据无限水平扩容，支撑高并发大流量业务；

  • 核心代价：牺牲SQL灵活性、降低事务一致性、大幅提升开发与运维复杂度、衍生各类分片专属问题。

6.2 跨库分页、排序难题（含代码实战）

分片场景下，传统 limit offset,size 分页完全失效。由于数据分散在多分片，单分片排序结果无法代表全局，直接查询会出现数据错乱、漏数据、重复数据问题。

6.2.1 内存分页（中小数据量通用）

查询所有分片数据，在应用层完成全局排序与分页，彻底解决分页错乱问题。

/**
 * 分片内存分页工具类
 * 解决：多分片limit offset分页数据错乱、漏数据问题
 */
public class ShardingPageUtil {
    /**
     * 多分片数据统一分页排序
     * @param allShardingData 所有分片查询出来的原始数据
     * @param pageNum 当前页
     * @param pageSize 每页条数
     * @return 分页结果
     */
    public static <T extends Comparable<T>> List<T> shardingPage(List<T> allShardingData, int pageNum, int pageSize) {
        // 1. 全局排序（必须和SQL排序字段保持一致）
        List<T> sortedList = allShardingData.stream()
                .sorted(Comparator.reverseOrder())
                .collect(Collectors.toList());
        // 2. 计算分页偏移量
        int start = (pageNum - 1) * pageSize;
        int end = Math.min(start + pageSize, sortedList.size());
        // 3. 分页截取返回
        return sortedList.subList(start, end);
    }
}

6.2.2 游标分页（深分页/大数据量最优）

摒弃offset偏移量，基于主键ID游标分页，无性能衰减，适配千万级数据深分页场景。

/**
 * 分片游标分页查询（解决深分页性能灾难）
 * 核心：不传offset，仅传递上一页最后一条数据ID
 */
@Mapper
public interface OrderMapper {
    // 每页10条，查询大于游标ID的最新数据
    @Select("select * from t_order where id > #{lastId} order by id limit 10")
    List<Order> listOrderByCursor(@Param("lastId") Long lastId);
}

6.3 跨分片Join关联问题与解决方案

分片架构严格禁止跨库Join，跨分片关联查询会直接报错或数据异常，生产通用三套解决方案：

  1. 优先携带分片键查询（最优无侵入）：所有关联查询强制携带分片键，保证关联数据落在同一分片，原生支持SQL Join；

  2. 应用层手动Join（代码实战）：无法同分片时，代码层分别查询数据后组装，替代SQL关联；

  3. 字段冗余设计（根治方案）：核心关联字段直接冗余至主表，彻底消灭跨表关联查询需求。

/**
 * 分片跨表关联：应用层手动Join示例
 * 场景：订单表、订单详情表分片存储，无法跨分片Join
 */
@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private OrderItemMapper orderItemMapper;

    public OrderVO getOrderDetail(Long orderId) {
        // 1. 根据分片键查询主表数据
        Order order = orderMapper.selectById(orderId);
        // 2. 根据相同分片键查询子表数据（同分片，无跨库）
        List<OrderItem> itemList = orderItemMapper.listByOrderId(orderId);
        // 3. 应用层组装关联数据
        OrderVO vo = new OrderVO();
        BeanUtils.copyProperties(order, vo);
        vo.setItemList(itemList);
        return vo;
    }
}

6.4 分布式事务分级与生产方案

分片事务分为多层级，需根据业务一致性要求选型，同时区分Sharding事务与Seata事务的使用场景。

6.4.1 事务场景区分

  • Sharding-JDBC事务：解决同一服务内多分片库表的事务一致性问题；

  • Seata事务：解决微服务跨服务分布式事务问题，与Sharding事务互补。

6.4.2 事务等级细分（生产&面试核心）

  • 弱XA（最终一致性）：Sharding原生支持，无锁高性能，适配普通业务，允许极短时间数据不一致；

  • 强XA（强一致性）：两阶段提交，性能差、阻塞风险高，生产极少使用；

  • BASE柔性事务：Sharding+Seata AT/TCC，高可用高并发，适配支付、交易核心场景。

6.4.3 代码实战：Sharding弱XA事务

/**
 * Sharding-JDBC 原生分布式事务（弱XA）
 * 同一服务、多分片库表写入，保证事务整体一致性
 */
@Service
@Transactional(rollbackFor = Exception.class)
public class OrderTransactionService {
    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private OrderItemMapper itemMapper;

    public void createOrder(Order order, OrderItem item) {
        // 写入分片1：订单主表
        orderMapper.insert(order);
        // 写入分片2：订单详情表
        itemMapper.insert(item);
        // 模拟异常，触发全分片事务回滚
        int i = 1 / 0;
    }
}

6.5 数据倾斜与热点分片（生产重大隐患）

问题描述：部分分片的数据存储量、读写QPS远高于其他分片，形成单点热点，导致单分片CPU、IO、连接数打满，引发全局接口卡顿、超时、性能抖动。

核心成因：分片键设计不合理、头部大用户/热点商品流量集中、哈希散列不均、时序分片天然热点聚集。

全套落地治理方案：

  • 热点数据单独分片：头部大用户、热点商品单独路由至专属分片，隔离热点流量；

  • 复合分片打散数据：基础分片键+随机后缀二次哈希，解决单一维度数据集中问题；

  • 虚拟分片映射：逻辑分片与物理分片解耦，支持动态数据重分布，无需全量迁移；

  • 数据定期均衡：监控分片容量差异，对超量分片数据灰度迁移、均衡打散；

  • 冷热分片隔离：热数据用哈希分片保证均衡，冷数据用范围分片方便归档。

6.6 分片倍数扩容方案与代码适配

哈希取模分片不支持任意扩容，仅支持2倍、4倍、8倍倍数扩容，可最大限度减少数据迁移量，是行业标准扩容方案。

/**
 * 分片扩容兼容算法
 * 适配旧分片2库 → 新分片4库灰度扩容，兼容新旧路由规则
 */
public class ShardingExpandAlgorithm {
    // 旧分片总数
    private static final int OLD_SHARD_COUNT = 2;
    // 新分片总数
    private static final int NEW_SHARD_COUNT = 4;

    public static int getShardIndex(Long shardingKey) {
        // 灰度阶段：老数据走旧分片规则，新数据走新规则
        if (isOldData(shardingKey)) {
            return (int) (shardingKey % OLD_SHARD_COUNT);
        }
        return (int) (shardingKey % NEW_SHARD_COUNT);
    }

    // 根据ID时间区间区分新旧数据
    private static boolean isOldData(Long key) {
        return key < 10000000L;
    }
}

6.7 Sharding-JDBC SQL黑名单（生产严格禁止）

分片架构存在SQL语法限制，以下语句生产严格禁止使用，避免报错、数据错乱与性能雪崩：

  • 禁止使用 limit n,-1 无偏移模糊分页；

  • 禁止跨库跨分片 join 关联、复杂嵌套子查询；

  • 禁止无分片键全局 group by、count(*)、sum 聚合查询；

  • 禁止自定义函数、存储过程、批量跨分片DDL操作。

6.8 DDL运维难题与自动化解决方案

分库分表后数据表分散在多库多表，传统单表DDL操作极易出现漏改、错改、结构不一致问题。生产标准方案：基于ShardingSphere管控平台或自定义自动化脚本，批量遍历全部分片库表统一执行DDL，变更后自动校验结构一致性，杜绝运维事故。

6.9 分片雪崩、穿透问题与高可用降级

分片架构核心线上风险：无分片键查询穿透、单分片故障引发全局雪崩。

6.9.1 核心风险定义

  • 分片穿透：无分片键、非法分片键查询，触发全分片广播扫描，压垮所有数据库节点；

  • 分片雪崩：单分片宕机、慢SQL阻塞，导致全局查询超时、服务雪崩；

  • 热点穿透：流量集中单一热点分片，单点瓶颈拖垮整体架构。

6.9.2 高可用解决方案

  • 强制分片键校验：网关/业务层拦截无分片键查询，禁止全分片广播；

  • 分片粒度熔断隔离：基于Sentinel实现单分片熔断，单点故障不扩散；

  • 热点缓存兜底：高频只读查询做本地/Redis缓存，减少分片查询压力；

  • 非核心业务降级：分片异常时关闭非核心查询，保障核心交易业务可用。

6.10 跨分片聚合统计解决方案

无分片键的全局COUNT、SUM、GROUP BY无法直接通过SQL执行，标准生产方案：分片预聚合 + 应用层全局聚合。

/**
 * 分片聚合通用工具
 * 解决跨分片count、sum、group by 数据统计不准问题
 */
public class ShardingAggUtil {
    // 各分片局部聚合后，全局汇总统计
    public static Map<Integer, Long> globalGroupBy(List<Map<Integer, Long>> shardingAggList) {
        Map<Integer, Long> resultMap = new HashMap<>();
        for (Map<Integer, Long> shardingMap : shardingAggList) {
            shardingMap.forEach((status, count) -> 
                resultMap.put(status, resultMap.getOrDefault(status, 0L) + count)
            );
        }
        return resultMap;
    }
}

6.11 多维度无分片键查询终极方案

针对多条件模糊查询、非分片键检索等MySQL分片无法支撑的场景，企业级标准复合架构：MySQL分片（存储+事务） + ES（检索兜底）

  • 写操作：数据落地MySQL分片，通过Canal同步Binlog至ES；

  • 读操作：带分片键精准查询走MySQL，复杂模糊检索走ES查询ID，再回查MySQL拿完整数据；

  • 兼顾数据一致性与检索灵活性，彻底解决分片查询局限性。

七、生产级零停机数据迁移方案

分库分表改造最大落地难点是线上数据迁移，核心要求：业务无感知、数据零丢失、零错乱、不停机迭代。

7.1 停机迁移（仅测试/小型项目）

流程：停止业务写入 → 全量导出旧库数据 → 按分片规则导入新库 → 数据校验 → 切换数据源重启服务。优点是实现简单，缺点是需要停机，不适合生产核心业务。

7.2 双写+Binlog不停机迁移（生产唯一标准）

基于Canal/Debezium Binlog增量同步+代码双写兜底，杜绝纯代码双写的数据丢失风险，全程业务无感知。

  1. 架构部署准备：搭建分片新库新表，配置Sharding路由规则，完成环境预验证；

  2. 开启Binlog增量同步：监听旧库Binlog，实时同步新增、修改、删除数据至新分片库；

  3. 代码双写兜底：业务层开启新旧库双写，弥补Binlog同步异常漏洞，保证增量零遗漏；

  4. 全量历史补数：分批批量迁移存量历史数据，规避大表锁表、数据库压垮问题；

  5. 多层数据校验：总量核对、明细比对、去重幂等校验，修复差异数据；

  6. 灰度流量切换：10%→50%→100%渐进切流，监控性能、报错、数据一致性指标；

  7. 全量切换稳定观测：全切新架构，关闭旧库写入，持续观测7-15天；

  8. 旧数据归档清理：业务稳定后，归档清理旧库冗余数据，完成改造。

7.3 迁移幂等、去重与数据保障机制

双写迁移核心风险为数据重复、错乱、丢失，必须配套完整保障机制：

  • 幂等写入：基于业务唯一主键、唯一索引拦截重复写入，从根源防重；

  • 自动化去重：迁移脚本内置去重逻辑，自动过滤脏数据、重复流水数据；

  • 三层校验机制：实时增量校验、定时全量校验、人工抽样校验结合；

  • 差异自动修复：配套比对工具，自动识别数据差异，支持一键补数、回滚修复。

八、生产高频坑点与避坑指南

  • 禁止修改分片键：分片键写入后不可修改，修改会导致数据路由错乱，无法修复；

  • 杜绝无分片键查询：无分片键查询触发全分片广播，造成性能雪崩；

  • 规范使用广播表/绑定表：字典表统一广播、关联表统一绑定，规避跨分片查询与Join问题；

  • 规避违规SQL语法：严格遵守SQL黑名单，不使用分片不兼容语法；

  • 监控数据倾斜：实时监控分片数据量、QPS，提前处理热点分片；

  • 区分读写分离+分片叠加架构：写走主库、读走从库，延迟敏感业务强制读主，避免数据不一致。

九、生产监控、灰度规范与运维体系

9.1 分片核心监控体系

分片上线必须配套监控，提前发现性能隐患与数据异常，核心监控指标：

  • 分片数据量监控：统计每库每表数据条数，阈值告警，提前发现数据倾斜；

  • 分片QPS监控：监控各分片读写流量，快速识别热点分片；

  • 慢SQL监控：捕获无分片键扫描、跨分片查询等慢SQL；

  • 事务成功率监控：监控分布式事务回滚率、异常率，保障数据一致。

9.2 灰度上线规范

分片改造禁止全量切流，必须遵循标准化灰度流程：测试环境验证 → 预发全量校验 → 线上10%灰度 → 50%流量放量 → 100%全量切换，全程监控接口性能、报错率、数据一致性。

9.3 压测与容量评估规范

  • 容量标准：单分片数据量控制在500w以内，单库QPS控制在1w以内，预留30%扩容余量；

  • 压测核心：分片路由性能、无分片键拦截、事务成功率、并发负载均衡度；

  • 上线标准：响应时间、TPS、错误率、回滚率全部达标方可上线。

9.4 线上故障排查方法论

  • 数据错乱：排查分片键设计、路由算法、双写迁移时序；

  • 查询缓慢：排查全分片广播、无分片键查询、单分片热点、慢SQL；

  • 事务异常：排查分片事务模式、Seata配置、跨分片写入逻辑；

  • 负载不均：比对各分片数据量、QPS，定位数据倾斜与热点问题。

十、面试总结与项目全流程落地规范

10.1 分库分表完整落地流程（企业标准）

标准化改造流程，杜绝随意开发上线：业务评估 → 架构选型 → 分片键设计 → 算法选型 → 代码开发 → 单元测试 → 压测验证 → 数据迁移 → 灰度上线 → 监控运维 → 迭代优化

10.2 三类核心表面试对比总结

表类型存储特点核心作用适用场景
分片表数据分散多库多表拆分海量数据，降低单表负载订单、流水、交易核心大表
广播表全分片数据完全一致避免跨分片字典查询字典、系统配置、常量表
绑定表分片键一致、分片位置一致彻底杜绝跨分片Join订单+订单详情等关联业务表

10.3 分片算法面试核心总结

哈希取模分片：数据均匀、无热点，适配核心交易业务，仅支持2/4/8倍数扩容，非倍数扩容需全量迁移；范围分片：扩容零成本、无需迁移历史数据，但存在永久热点分片，禁止用于核心交易业务，仅适配时序日志数据。

10.4 全文终总结

分库分表是MySQL海量数据扩容的最后手段，严格遵循「能优化不归档、能归档不分片」的架构准则。本文完整覆盖分片底层原理、算法设计、中间件选型、代码实战、生产难题、零停机迁移、监控运维、故障排查与面试考点，形成完整知识闭环。生产最优架构组合：Sharding-JDBC + 倍数扩容 + Binlog双写迁移 + ES检索兜底 + 分片监控熔断，可稳定支撑千万至亿级数据高可用、高性能、长期迭代运行。

avatar
文章
阅读
粉丝