如何做到MySQL高扩展性
0. 引言
业务增长到单机极限后，扩展性成为架构主旋律。**垂直扩展（Scale-Up）**升级硬件，有物理天花板；**水平扩展（Scale-Out）**加机器分摊，理论上无限。本文给出从"单机调优"到"分库分表"再到"分布式数据库"的完整扩展路径，以及万亿级数据量的应对方法论。
1. 高并发与扩展的基本方法
图表渲染中…
| 维度 | Scale-Up（垂直） | Scale-Out（水平） |
|---|---|---|
| 手段 | 加 CPU/内存、换 NVMe、参数调优 | 加机器：主从、分片、集群 |
| 天花板 | 单机物理上限 | 理论无上限（受元数据/协调限制） |
| 成本 | 高性能硬件昂贵且非线性 | 普通机器线性扩展 |
| 复杂度 | 低 | 高（分片键设计、跨片查询、一致性） |
| 适用 | 中等规模、短期扩容 | 长期规划、海量数据 |
2. 垂直扩展（Scale-Up）
- 硬件：CPU 主频/核数、内存（Buffer Pool 命中率）、NVMe SSD（详见《如何突破单库性能瓶颈》）；
- 参数：redo 容量、刷盘策略、连接数、临时表内存化；
- 架构优化：去掉无索引查询、热点行拆分（行锁竞争）、大字段拆表；
- 分区表：
PARTITION BY RANGE按时间分区，配合分区裁剪（WHERE created_at只扫分区）。注意：8.0 分区要求唯一键必须包含分区键，且分区不能解决单机瓶颈（只是物理文件拆分）——大表优先考虑分表而非分区。
3. 水平扩展（Scale-Out）
3.1 第一层：主从复制 + 读写分离
读扩展（见《如何突破单库性能瓶颈》）：一主多从，读 QPS 线性增长。写仍是单点。
3.2 第二层：数据分片（Sharding）
分库分表是写扩展的核心手段（详见《为什么需要分库分表，如何实现》）：
- 分片键选择：业务访问最频繁的维度（用户 ID、订单 ID）；
- 分片算法：哈希取模、范围、一致性哈希；
- 分片数量预估：按 3-5 年数据增长规划，尽量一次到位（扩容代价高，见《分库分表以后，如何实现扩容》）；
- 代价清单：跨片 JOIN 不可用（冗余/宽表/应用层聚合）、分布式事务（尽力而为/Seata）、全局唯一 ID（雪花）、跨片分页（合并排序）。
3.3 第三层：数据库中间件
| 中间件 | 定位 | 特点 |
|---|---|---|
| ShardingSphere（Apache 顶级项目） | 分库分表 + 读写分离 + 数据加密 | JDBC 直连（性能好）/Proxy 代理（语言无关）双形态；8.0 兼容性好，社区活跃 |
| MyCat | 代理式分片中间件 | 国内老牌，配置管理简单；性能损耗在代理层 |
| Vitess | 云原生分片（YouTube 出品） | K8s 生态、大规模案例 |
| ProxySQL | 读写分离/连接池 | 专注流量治理，不承担分片 |
选型建议：Java 团队新项目 → ShardingSphere-JDBC（集成简单、性能好）；异构语言/统一管控 → ShardingSphere-Proxy 或 MyCat；上云 → 云原生数据库（PolarDB/TDSQL 等自带扩展）。
3.4 第四层：集群化
- MGR/InnoDB Cluster：高可用 + 有限扩展（读写分离场景）；
- 云 RDS 集群：云厂商托管的读写分离 + 只读实例扩展，运维成本最低。
4. 分布式数据库（NewSQL）
当分库分表的管理成本（分片键约束、跨片事务、扩容）超过收益时，考虑原生分布式数据库：
| 数据库 | 类型 | 特点 |
|---|---|---|
| TiDB | 分布式 HTAP（NewSQL） | MySQL 协议兼容（业务可无痛迁移）、TiKV 存储 + Raft 共识 + 自动分片（Region 自动分裂合并）、水平扩展透明、强一致 |
| OceanBase | 分布式关系库 | 蚂蚁集团出品，金融级，MySQL/Oracle 兼容 |
| PolarDB-X | 云原生分布式 | 阿里云，MySQL 生态 |
| ClickHouse | OLAP 分析 | 列式存储，不适合 OLTP |
TiDB 适合：数据量 10TB+、需要透明扩展与强一致、希望保留 MySQL 开发习惯的场景；不适合：超高频短事务（单行延迟略高于 MySQL）、复杂跨表事务依赖分布式事务性能的场景。
5. 万亿级数据量应对技巧
- 冷热分层：热数据（近 30 天）在 MySQL/TiDB，冷数据归档到对象存储/OLAP（数据生命周期管理）；
- 时间维度分片：日志/流水类数据按天/月分表，配合定期归档（DROP 过期分区秒级）；
- 预聚合：明细入库 + 实时聚合（Flink）+ 结果表，报表查询不碰明细；
- 缓存兜底：热点读走 Redis，数据库只承担"缓存未命中"流量；
- 只读副本：分析查询跑只读副本，不干扰在线事务；
- 数据压缩：8.0 透明页压缩（
COMPRESSION=ZLIB）或列式归档表。
6. 重点总结
- 扩展三阶段：Scale-Up（单机）→ Scale-Out（主从/分片）→ Distributed（NewSQL），每步都有明确触发条件；
- 分库分表是"最后的武器"：分片键设计决定命运，跨片复杂度需提前消化；
- 中间件选型：ShardingSphere 是 Java 生态事实标准，Proxy 形态适合异构团队；
- 数据量真到"万亿级"时，用分布式数据库 + 冷热分层 + 预聚合组合拳，别硬撑单机。
下一章讲解海量数据 MySQL 项目实战：从架构设计到容量规划的全流程案例。