何时考虑分库分表？决策时机与评估方法

分库分表不是银弹

分库分表（Sharding）是解决数据库可扩展性问题的手段之一，但引入后带来的复杂度不可忽视。在做这个决策前，先问自己三个问题：

1. 是否已经用尽了其他优化手段？
2. 分库分表能否解决当前的瓶颈？
3. 业务能否承受架构变更带来的成本？

需要考虑分库分表的场景

场景一：数据量超出单机承载上限

核心判断标准：单表数据行数超过千万级，且每月增量达到百万级以上。

当数据量达到这个规模时，即使所有查询都走索引，以下问题也会逐渐显现：
– B+Tree 索引层数加深（3-4 层 → 4-5 层），IO 次数增加
– 数据文件大小超过单机磁盘上限
– 备份耗时以小时乃至天计

场景二：写入吞吐达到单机极限

核心判断标准：单一 MySQL 实例的 TPS 已接近硬件上限，垂直扩容不再显著提升性能。

典型表现：
– CPU 使用率持续 80%+
– 磁盘 IOPS 打满
– 大量写入因 redo log 写入瓶颈排队

场景三：连接数成为瓶颈

核心判断标准：应用实例数持续扩张，每个实例的连接池导致总连接数接近或超过 MySQL 上限。

场景四：热点数据过于集中

某些表（如订单表、用户表）承担了 80% 的读写流量，而其他表几乎没有压力。这时候就需要将这些热点表拆分出去。

还不应该考虑分库分表的时机

经验法则：数据量在 5000 万以下、单库 QPS 在 10000 以内，先尝试优化而非分库分表。

决策流程

检测到性能瓶颈
    │
    ▼
是否还有优化空间？──────是──→ SQL 优化 / 索引 / 缓存
    │
    否
    │
    ▼
单机垂直扩容是否可行？────是──→ 升级硬件配置
    │
    否
    │
    ▼
读写分离是否足够？────────是──→ 一主多从 + 读写分离
    │
    否
    │
    ▼
业务场景是否适合分片？────否──→ 考虑 NoSQL 或其他方案
    │
    是
    │
    ▼
实施分库分表

业务场景评估

适合分库分表的业务特征：
– 数据可以按某个维度（用户 ID、订单 ID）自然切分
– 跨分片查询较少
– 事务大多在单个分片内完成

不适合分库分表的业务特征：
– 大量跨分片 JOIN 和事务
– 全局排序和分页频繁
– 数据间关联紧密，难以按维度拆解

分库分表前的前置工作

1. 数据量评估：预估当前增速和未来 2-3 年的数据量
2. 分片键选择：找到查询最频繁的维度字段
3. 迁移方案设计：停机迁移 vs 平滑迁移
4. 中间件选型：Sharding-JDBC、MyCat、ShardingSphere 等
5. 灰度验证：先在部分流量上验证

面试要点

• 分库分表是最后的手段，不是第一选择
• 清晰描述决策条件和优先级排序
• 能够列举不需要分库分表的场景及其替代方案
• 强调业务维度评估的重要性：无合适的片键就不要做
• 理解分库分表引入的复杂度：跨库事务、Join、排序、迁移