mysql的单表多大要考虑分库分表

一、问题背景

第一个问题，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 万行以内就切分。

---

✅ 总结：

1. 单表行数：<5000 万推荐，过亿要分表。

2. 单库 QPS：写 3000–5000 是常见上限，读 5 万–10 万。

3. 触发拆分条件：

   • 单表 >5000 万行

   • 单库存储 >200GB

   • 写 QPS >3000–5000

---