一、问题背景
第一个问题，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
-
