一、問題背景

第一個問題，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