我是資料庫系統設計的新手。在閱讀了很多文章後，我真的很困惑我們應該有 1 個表格而不進行分片或分區的限制是多少。我知道提供通用答案確實很困難，事情取決於諸如
之類的因素
- 行的大小
- 資料型別（字串、blob 等）
- 活躍查詢數量
- 什麼樣的查詢
- 索引
- 重讀/重寫
- 預期延遲
但是當有人問這個問題
- 如果每天有 10 億個資料和數百萬行添加，您會怎麼做？對於如此大的資料庫，4 次讀取、1 次寫入和 2 次更新查詢的延遲需要低於 5 毫秒。
- 如果您只有 1000 萬行，但更新和讀取量很高，您會選擇什麼？新增的新行數並不重要。高一致性、低延遲是要求。
如果行數少於一百萬，並且行大小增加數千，那麼選擇很簡單。但當選擇涉及數百萬或數十億行時，事情就會變得更加棘手。
注意：我在問題中沒有提到延遲數。請
根據您可以接受的延遲數回答。另外，我們正在討論結構化資料。
我不確定，但我可以添加 3 個具體問題：
- 假設您為亞馬遜或任何電子商務訂單管理系統選擇 SQL 資料庫。訂單數量每天都在以百萬計的速度增加。已經有10億筆記錄了。現在，假設沒有資料存檔。每秒有超過一千個查詢的高讀取查詢。並且也有寫入。讀：寫比例為100：1
- 讓我們舉一個現在較小的數字的例子。假設您為 abc 或任何電子商務訂單管理系統選擇 SQL 資料庫。訂單數量每天都在增加數千。已經有1000萬筆記錄。現在，假設沒有資料存檔。每秒有超過一萬個查詢的高讀取查詢。並且也有寫入。讀寫比例為10:1
- 第三個範例：免費贈品分發。我們有1000萬件好東西要分發。每個使用者 1 件好東西。高一致性、低延遲是目標。假設已經有 2000 萬用戶在等待免費分發，一旦時間開始，他們所有人都會嘗試獲得免費的好東西。
注意：在整個問題中，假設我們將選擇
SQL 解決方案。另外，如果提供的用例在邏輯上沒有意義，請忽略。目的是獲取數字方面的知識。
有人可以幫忙了解基準是什麼嗎？您目前正在從事的專案中的任何實際數字都可以表明，對於具有如此多查詢的大型資料庫，這就是觀察到的延遲。任何可以幫助我證明針對特定延遲的一定數量的查詢選擇表數量的合理性的任何東西。
MySQL 的一些答案。由於所有資料庫都受到磁碟空間、網路延遲等限制，其他引擎可能類似。
SELECT是可能的。所以你需要了解查詢是否是這樣病態的。 （我認為這是高“延遲”的一個例子。）PARTITIONing（尤其是在 MySQL 中）的用途很少。更多詳細資訊：分區INDEX對於效能非常重要。每天插入一百萬行不是問題。 （當然，有些模式設計可能會導致這個問題。）經驗法則：100/秒可能不是問題；1000/秒可能是可能的；之後就變得更難了。更多關於高速攝取當您進入大型資料庫時，它們分為幾種不同的類型；每個都有一些不同的特徵。
SPATIAL或一些技術 此處