一、问题背景
第一个问题,mysql的话,一般单表行数达到多少性能会开始明显下降,然后一般推荐单表行数到多少建议做分库分表呢;第二个问题,mysql的单库最大可支持的qps是多少,一般qps到了多少之后,会推荐进行分库呢
二、问题分析
1. 单表行数多少开始明显下降?
-
官方理论:
-
InnoDB 本质上可以支撑 亿级行数(单表 10 亿行甚至更多,取决于存储和索引设计)。
-
MySQL 官方 InnoDB 限制 并没有给出硬性“最大行数”,而是说由 页大小、索引树高度、磁盘空间 决定。
- 阿里的开发手册中有条建议,单表行数超500万行或者单表容量超过2GB,就推荐分库分表
-
-
实践经验(互联网公司):
-
千万级行数以内(1,000 万–5,000 万):只要索引合理,性能基本稳定。
-
过亿行:查询/更新延迟会开始明显上升(B+ 树层级增加、缓存命中率下降、主从复制压力大)。
- 正常是应该像阿里这样的,然而理想和实现总是有差距的,阿里这种体量的公司不差钱当然可以这么用,实际上很多公司单表数据几千万、亿级别仍然不选择分库分表。
-
电商/支付系统常规推荐:
-
单表 <5,000 万 行是安全区。
-
接近 1 亿行时,通常会提前分表。
-
-
2. 单库最大可支持的 QPS?
-
官方角度:
-
MySQL 官方不会给具体 “QPS 上限”,但 Performance Schema 指南 推荐通过 压测评估。
-
-
实践经验(单机 MySQL 8.0 + InnoDB,SSD 环境):
-
读为主(主从架构 + 只读从库):单库 QPS 可达 5 万–10 万。
-
写为主(事务型,电商/支付常见):单库 QPS 通常在 2 千–5 千 区间更稳健。
-
峰值案例:
-
阿里双 11:单库写 QPS 稳定在 3 千–5 千,读 QPS 借助读写分离 + 缓存可以到 10 万。
-
PayPal/Stripe:支付交易库单实例写 QPS 通常不超过 2 千–3 千,超过就会水平拆分。
-
-
-
常见分库阈值:
-
写 QPS > 3 千–5 千 → 考虑分库分表。
-
存储容量 > 200GB/单库 或 单表 > 5,000 万行 → 也会触发拆分。
-
3. 官方文档 & 实际案例
-
官方:
-
InnoDB 限制:https://dev.mysql.com/doc/refman/8.0/en/innodb-restrictions.html
-
性能 Schema:https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html
-
MySQL 8.0 Capacity Planning(存储 & 索引参考):https://dev.mysql.com/doc/refman/8.0/en/optimizing-innodb.html
-
-
案例:
-
阿里巴巴(双 11 架构分享):单表超过 5000 万 行会触发自动分表,单库写 QPS 稳定不超过 5000。
-
美团(技术博客):单库写压测 QPS 在 3000–4000 左右,超过会拆分。
-
京东:单表 1 亿行以内仍能跑,但复杂查询会明显变慢,因此通常 5000 万行以内就切分。
-
✅ 总结:
-
单表行数:<5000 万推荐,过亿要分表。
-
单库 QPS:写 3000–5000 是常见上限,读 5 万–10 万。
-
触发拆分条件:
-
单表 >5000 万行
-
单库存储 >200GB
-
写 QPS >3000–5000
-