MySQL 分库分表：什么时候需要，怎么设计？

Wed, 11 Sep 2024 00:00:00 +0000

MySQL 分库分表：什么时候需要，怎么设计？

MySQL 的单机能力并不是无限的。

当数据规模、并发请求和存储需求持续增长时，即使已经完成索引优化、SQL 优化、缓存、连接池和读写分离，单个 MySQL 实例仍然可能成为系统瓶颈。

这时候才需要考虑一个更重的方案：

分库分表（Sharding）。

分库分表本质上是把原来集中在一个数据库中的数据和请求拆开，让多个数据库实例共同承担存储和访问压力。

但需要注意：

分库分表解决的是容量和并发扩展问题，并不会自动让每一条 SQL 都变快。

而且一旦进入分库分表阶段，原本简单的 SQL、事务、分页、JOIN、统计查询都会变得更加复杂。

因此，分库分表最重要的不是“怎么拆”，而是什么时候拆，以及按照什么规则拆。

1. 为什么需要分库分表

假设有一张订单表：

CREATE TABLE orders (
 id BIGINT PRIMARY KEY,
 user_id BIGINT NOT NULL,
 status TINYINT NOT NULL,
 amount DECIMAL(12, 2) NOT NULL,
 created_at DATETIME NOT NULL,
 KEY idx_user_id (user_id),
 KEY idx_created_at (created_at)
);

随着业务增长，这张表可能达到数亿甚至更大的数据量。

问题可能来自几个方面。

单表数据量过大

表越来越大以后：

索引越来越大；
Buffer Pool 缓存命中率下降；
查询和更新涉及更多磁盘 I/O；

数据库架构 on Leanku 的博客

MySQL 分库分表：什么时候需要，怎么设计？

MySQL 分库分表：什么时候需要，怎么设计？

1. 为什么需要分库分表

单表数据量过大