MySQL单表能存21亿条吗？亿级数据性能优化与分库分表实战解析

这是一个困扰了很多人的经典问题，我早期刚接触MySQL时也跟同事争论过。今天不打算只丢一个结论，而是把背后的原理、实际测试数据、以及真正会遇到的性能瓶颈一一道来，希望能帮到正在纠结“要不要拆表”、“要不要分库”的你。

先直接说结论：MySQL单表确实可以存下21亿条数据，但99%的业务场景下，当数据量达到这个级别时，性能大概率会出现严重问题。所以问题的关键不在于“能不能存”，而在于“你怎么存、怎么查、怎么维护”。

1. 21亿这个数字到底是怎么来的

1.1 int主键的上限就是21.47亿

很多人对“21亿”这个数字有种天然的敬畏感，其实它并没有那么神秘。MySQL默认的整数类型int是4个字节，也就是32位，最大能表示的带符号整数是2^31-1，即2147483647，约21.47亿。这也就是很多公司里的主键ID用int类型时会遇到的“溢出”问题的根源。一旦数据量接近这个上限，int主键就会不够用，必须改用bigint。

所以我们常说的“单表能存21亿条”，本质上是指“int主键的最大容量”。如果你的表用的是bigint主键，那上限就是9.22×10^18，可以说几乎永远不会主键溢出。但这只解决“ID还够不够用”的问题，跟“查询是否顺畅”完全是两回事。

1.2 存储引擎能装下，InnoDB的B+树也能撑住

InnoDB引擎的表空间默认情况下支持单表最大64TB（取决于文件系统和innodb_data_file_path配置）。如果每条记录按1KB计算，21亿条数据约占2TB左右的磁盘空间，完全在InnoDB的物理容量范围内。所以从纯容量的角度来讲，单表存21亿条是可行的。

另外，InnoDB使用B+树作为聚簇索引结构，B+树的节点大小默认为16KB。每个非叶子节点能存放大约1200个索引项（16KB除以大概13字节的索引条目开销）。三层B+树大概能支撑1200×1200×1200约为17亿条记录，四层则能轻松覆盖上百亿条。意思是从索引深度的角度看，21亿条数据仍然只需要4层B+树，查询时最多做3~4次磁盘IO，并不是那种“索引深到没法用”的情况。

但这里有个很多人会误解的点：B+树的层数增长很慢，不代表数据量大了查询就一定不慢。真正的问题通常不是树的高度，而是索引命中率、随机IO、排序开销、锁竞争等这些“隐形杀手”。

2. 单表过亿之后，性能瓶颈到底卡在哪

2.1 存储空间和内存的关系会被彻底打穿

机械硬盘时代，顺序IO和随机IO的差距非常大；即使现在很多生产环境用了SSD，随机IO的延迟也远高于顺序IO。当单表数据量从1000万涨到2亿，如果不加筛选条件做全表扫描，MySQL需要扫描的数据页数量会成倍增加，每个数据页对应一次磁盘IO，时间自然成倍拉长。

更核心的问题是内存。InnoDB有buffer pool，默认大小通常是128MB（生产环境一般会调大，比如总内存的70%以上）。假设单行数据平均1KB、表总量50GB，而buffer pool只有16GB，那意味着最高只有约30%的数据能留在内存里。查询一旦落到不在内存中的热数据页，就要发生磁盘交换，造成明显的性能抖动。数据量越大，“缓存命中率”下降得越快，这是很多DBA最头疼的事。

2.2 索引不是越多越好，维护成本和查询计划都会恶化

单表数据量大了以后，一个常见的惯性操作是“给经常查的字段都加上索引”，但实际效果往往适得其反。每个二级索引都是一棵独立的B+树，数据量越大，索引占用的空间就越大，写入时需要同步维护的索引越多，写性能下降越明显。

同时，MySQL优化器会基于统计信息选择执行计划。数据量一大，统计信息的偏差可能导致本该走索引的查询变成全表扫描。还有一种典型场景：分页查询用了LIMIT + OFFSET，OFFSET一深，MySQL会把前面命中的记录全部扫一遍再丢弃，数据量越大，这种“深翻页”越慢。

2.3 大事务锁冲突与undo膨胀容易成为定时炸弹

21亿条数据的表，如果有批量更新或批量删除操作，很可能产生一个很大的事务。长事务意味着什么？行锁或间隙锁持锁时间变长，其他请求不得不排队等待；同时InnoDB的undo log会不断累积，如果事务一直不提交，还会导致purge线程无法清理历史版本，进而引发undo表空间膨胀，甚至出现“history list length”持续飙高的情况。

我见过一个真实案例：有人对一张几亿行的表执行DELETE FROM WHERE create_time < 某时间点，结果跑了快20分钟还没结束，期间整张表的写入全部被阻塞。原因就是这条语句生成了一个巨大的事务，锁范围覆盖了所有符合条件的行，同时还拖慢了binlog同步。这种场景下，不管数据量是2亿还是21亿，都会出问题。

3. 用数据说话：亿级单表MySQL到底什么表现

3.1 我先搭了个测试环境来跑真实数据

很多人喜欢凭感觉讨论单表的极限，但我觉得还是应该用数据验证。我搭了一套测试环境，配置如下，仅供参考，实际生产环境比这个要强劲一些：

• 服务器：8核16G，SSD磁盘
• MySQL版本：8.0.32，使用InnoDB引擎
• buffer pool设为12G，大约占服务器内存的75%
• 表结构：模拟一个订单表，包含自增ID、用户ID、订单号、订单金额、状态、创建时间等字段
• 造数方式：用存储过程循环插入，也可以通过LOAD DATA方式批量导入
• 最终数据量：约2.1亿行，平均行大小约900字节

我用这些数据做了几组典型查询，结果比较直观地反映了性能分布情况。

3.2 几组关键测试结果对比

以下结果是在冷缓存状态下测试的，也就是刚重启完MySQL后执行第一次查询的情况。如果你是反复执行同类查询，命中缓存后数据会更好看，但冷缓存更能代表“真实首次访问”的体验。

可以看出，主键点查的性能在2.1亿行时依然非常稳定，因为走的是聚簇索引，IO次数可控。但是二级索引查询在没覆盖索引时，需要回表，回表次数多后性能提升就被抵消了。范围查询和深分页是重灾区，不加优化的话动辄上秒，这在联机交易场景中直接会对接口响应造成影响。

3.3 写入性能的变化也不能忽视

读性能之外，我同样测了写入。插入2.1亿行后，再批量插入1万条记录，耗时显著上升。原因很简单：表上有多个二级索引，每插入一条数据，InnoDB都要同步更新多个索引B+树；同时随着表越来越大，新数据插入时也需要寻找可用的数据页，页分裂概率提高，随机IO增多。

这里要提醒一下，如果表上有自增主键，行插入通常追加到B+树最右侧，顺序IO为主，相对快。但如果你用的是随机生成的UUID作为主键，插入的IO模式会变成“随机插入”，性能会显著下滑。所以对于超大单表，主键设计非常关键。

4. 要想用得好，这几个优化手段必须掌握

4.1 索引优化：尽量让查询走覆盖索引

覆盖索引指的是：查询的所有字段都能在索引中找到，不需要回表。对亿级表来说，减少回表意味着减少大量随机IO，收益巨大。

举个例子，如果业务方经常查“某个用户的时间段内的订单总金额”，你可以设计联合索引(user_id, create_time)，然后查询语句里只select order_amount字段，并且create_time是索引的最左前缀，order_amount作为扩展字段放进索引叶子节点。这样整条查询全部在索引内部完成，速度会非常可观。

但联合索引不是越多越好，每个索引都会拖慢写入，还会占用额外存储空间。原则是：能用联合索引覆盖高频查询的，就尽量建；低频查询和报表类查询则考虑别在线上库死磕，放到从库或者数仓去跑。

4.2 对超大表做数据生命周期管理

这里说的“生命周期管理”是指：定期把历史数据归档出去，核心业务表只保留近期的热数据。比如订单表，线上只保留3个月的数据，3个月前的数据通过定时任务转移到历史表或归档库，这样线上单表能一直控制在几千万到1亿左右的规模，性能非常从容。

我见过不少互联网公司的做法是：用脚本按月按周做分区清理，或者把数据写入到历史库，然后通过视图来统一查询。这种方式的代价是要额外维护一套归档逻辑，但对核心链路的好处是立竿见影的。如果业务上必须要查到所有历史数据，可以在查询前加个标识区分“查近3个月”和“查全部”，避免每次都说全表扫。

4.3 必要时使用分区表，但要选对分区键

MySQL的原生分区表（Partitioning）在某些场景下确实是利器，比如按时间范围分区。对于21亿级别的历史流水数据，可以直接按照create_time的月份做RANGE分区，查询时如果条件包含分区键，MySQL会自动进行分区裁剪，只扫描特定分区，能让全表扫描变成单分区扫描。

但分区表不是万能药。如果查询条件不带分区键，反而可能扫描所有分区，比普通表还要慢。另外分区表在DDL变更、全局唯一键约束方面有限制，使用前需仔细确认需求。我之前踩过一个坑：分区表的主键必须包含分区键，如果业务上主键是id而想按user_id分区，就得改主键设计，这一点不提前评估很容易放飞自我。

4.4 分库分表：最后的选项

当单表数据量确实大到一定程度，比如索引维护困难、磁盘IO吃紧、写入吞吐不足时，才需要认真考虑分库分表。常见做法是按user_id或order_id做哈希分表，或按时间维度进行分片，再用ShardingSphere或MyCat之类的中间件做数据路由。

但分库分表的代价非常明显：全局唯一ID、跨库join、分布式事务、聚合查询都会变复杂。经常有人问“多少数据量要分库分表”，我的个人建议是：先做冷热分离、索引优化、参数调优，实在不够了再上中间件；如果每天新增数据量不大，1亿到2亿级别完全可以通过好硬件和好SQL撑着，不必盲目追求“分布式”。

5. 常见问题速查与排查技巧实录

5.1 我在处理这类问题时的排查流程参考

遇到“单表数据量过大导致查询/写入慢”的反馈，我的排查顺序通常是下面这样的：

1. 先看慢查询日志，定位具体是哪几类SQL慢，而不是笼统地说“系统慢”。
2. 用EXPLAIN看执行计划，确认有没有走索引，有没有出现全表扫描、临时表、filesort。
3. 看缓冲池命中率和InnoDB行锁等待情况，判断是内存不足还是锁竞争。
4. 用percona toolkit或sys库的语句检查是否存在大事务、长事务和undo堆积。
5. 再结合业务场景判断：是不是深分页导致的？是不是索引选择性不高导致的？

大多数情况下，问题的根源并不是“21亿数据本身”，而是某条SQL确实写得不够好，或者因为没有冷热分离，所有查询都压到了同一张超大的表上。把问题拆开看，解决思路就会清晰很多。

5.2 适合记在笔记本上的几条实战经验

第一，深分页优化可以改成“基于游标的分页”或“延迟关联”。延迟关联的思路是：先用二级索引去定位需要的ID集合，再回表拿剩余字段，而不是直接用OFFSET跳过去，效果立竿见影。

第二，大批量删除数据一定要切片。比如每天定时只删3个月前的数据，且每次删除不超过1万条，并且sleep一小段时间，避免单次大事务锁太久。

第三，复杂统计类SQL不要直接打主库。单表数据量上了亿，哪怕是走索引的SUM和COUNT也可能消耗不少CPU和IO，很容易影响线上主库的写入。稳妥做法是挂一个从库来跑报表，或者做一张汇总表。

第四，对超大表做DDL操作要慎之又慎。MySQL 8.0支持INSTANT算法添加列，但某些DDL依然可能锁表，建议用gh-ost/pt-online-schema-change来做在线变更，避免在业务高峰期执行。

第五，备份和恢复时也要考虑时间成本。一两个T的单表用mysqldump导数据可能要很久，建议使用物理备份工具（比如Percona XtraBackup），并提前演练恢复流程，不要在出故障时才发现恢复不了。

写到最后，说点我个人的体会

踩过这么多年坑之后，我对“MySQL单表能存多少数据”有了一个很现实的判断。如果你的表只用来写入和主键查询，存到21亿甚至更多问题也不大；如果你需要在上面做灵活查询、范围统计、复杂排序，那超过2亿条数据就已经到了一个临界点，必须对表结构、索引设计和数据形态做规划，不能指望一条SQL吃遍天。

在我实际处理的案例里，绝大多数所谓“单表21亿撑不住”的情况，追根溯源都是没有做数据生命周期管理，或者SQL没有利用好索引。真正确认是“表太大必须拆分”的案例，反而集中在业务写入并发极高和存储达到数TB的场景。

所以，下一次再有人问“MySQL单表能存21亿条吗”，你可以给出一个更成熟的回答：能存，但你要想清楚怎么查、怎么维护、怎么扛住写入。数据库永远都不只是“存”的问题，真正考验的是你在数据膨胀之前，有没有提前设计好一条可持续演进的路。