2026/7/23大约 3 分钟
在数据库设计中，分表（Sharding / Partitioning） 主要是为了解决由“大数据量”和“高并发”带来的性能瓶颈。当一张表的数据达到千万甚至亿级时，查询和写入的效率会断崖式下跌。
分表通常分为垂直分表和水平分表两种逻辑：
1. 垂直分表 (Vertical Splitting)
做法： 把一张有很多字段的表，拆分成多张表，每张表存储一部分字段。通常是将“大字段”或“冷门字段”拆出去。
-
为什么要分：
-
减少 I/O 消耗： 数据库是以“页”为单位读取数据的。如果表太宽（字段太多），一页能存的行数就少，查询时需要加载更多的磁盘页。
-
提高并发能力： 减少锁的竞争。比如用户基本信息经常改，但用户详细背景介绍很少改，拆开后互不干扰。
-
例子： 将
User表拆分为User_Base（存储账号密码）和User_Detail（存储个人简介、头像等大文本）。
2. 水平分表 (Horizontal Splitting)
做法： 保持表结构不变，将数据行分布到不同的表中（如 order_2023, order_2024）。
-
为什么要分：
-
优化 B+ 树索引： InnoDB 存储引擎使用 B+ 树。当数据量过大，树的层级会变深，导致查询时的磁盘寻道次数增加，性能下降。
-
规避单表限制： 许多数据库单表在超过 2000 万行后，维护索引、修改表结构的成本会变得极高。
-
提升写入性能： 单表写入会有行锁或表锁竞争，分散到多张表可以实现并行写入。
-
例子： 按用户 ID 取模（
ID % 10），将数据分散到 10 张不同的表中。
3. 分表带来的核心收益
| 维度 | 分表前的痛点 | 分表后的改进 |
|---|---|---|
| 查询速度 | 扫描全表或巨型索引，速度极慢 | 缩小了扫描范围，索引更轻量 |
| 磁盘 I/O | 每次查询加载大量无关数据 | 只加载必要的字段或数据片 |
| 系统稳定性 | 单表故障或锁死导致全站瘫痪 | 风险分散，部分表损坏不影响整体 |
| 维护成本 | 备份、恢复、修改表结构（DDL）极其耗时 | 可以针对小表进行快速维护 |
4. 什么时候需要分表？
并不是所有项目都要分表，因为分表会带来分布式事务、跨表 Join 困难、分页查询复杂等副作用。通常以下情况才考虑：
- 单表行数过多： 比如 MySQL 单表超过 1000 万-2000 万行。
- 单表文件过大： 占用磁盘几十个 GB，备份和迁移非常困难。
- 高并发写入： 数据库连接数和锁竞争成为瓶颈。
你想了解具体的拆分策略（比如按时间、按哈希值）还是想知道在 Vue + Spring Boot 项目中如何通过代码实现分表？