表分區有什麼幫助？
我很難理解表分區的優缺點。我即將開始一個項目，該項目將有 8 個表，其中一個將是主數據表，將保存 180-2.6 億條記錄。因為它將是正確索引的表，所以我正在考慮將表記錄限制為 2000 萬，這樣我就必須創建 9-13 個表。
但是我不太確定它將如何提高性能，因為它們將位於同一台機器上（32GB RAM）？
我正在使用 MySQL，表將是 MyISAM，大表將在 id 欄位上有索引，並且沒有像全文搜尋等進一步的複雜性。
還請闡明表分區與數據庫分區。
以下只是瘋狂的咆哮和咆哮……
如果將所有數據保留在一個表中（無分區），則使用鍵的搜尋時間為 O(log n)。讓我們以世界上最糟糕的索引二叉樹為例。每個樹節點只有一個鍵。具有 268,435,455 (2^28 - 1) 個樹節點的完美平衡二叉樹的高度為 28。如果將此二叉樹拆分為 16 棵獨立的樹，則會得到 16 棵二叉樹，每棵樹有 16,777,215 (2^24 - 1)高度為 24 的樹節點。搜尋路徑減少了 4 個節點，高度減少了 14.2857 %。如果搜尋時間以微秒為單位，則搜尋時間減少 14.2857 % 幾乎可以忽略不計。
現在在現實世界中，BTREE 索引將具有帶有多個鍵的樹節點。每個 BTREE 搜尋都會在頁面內執行二進制搜尋，並可能下降到另一個頁面。例如，如果每個 BTREE 頁麵包含 1024 個鍵，則樹高 3 或 4 將是常態，實際上是短樹高。
請注意，表的分區不會降低已經很小的 BTREE 的高度。給定 2.6 億行的分區，甚至很有可能擁有多個具有相同高度的 BTREE。每次搜尋一個鍵可能會經過所有根 BTREE 頁面。只有一個會滿足所需搜尋範圍的路徑。
現在對此進行擴展。所有分區都存在於同一台機器上。如果每個分區沒有單獨的磁碟，那麼磁碟 I/O 和主軸旋轉將成為分區搜尋性能之外的自動瓶頸。
在這種情況下，如果 id 是唯一被使用的搜尋鍵，那麼按數據庫分區也不會給您帶來任何好處。
數據分區應該用於對在同一類中邏輯和內聚的數據進行分組。只要數據被正確分組，搜尋每個分區的性能不必是主要考慮因素。一旦你實現了邏輯分區，然後專注於搜尋時間。如果您僅按 id 分隔數據，則可能永遠不會訪問許多數據行以進行讀取或寫入。現在，這應該是一個主要考慮因素：找到所有最常訪問的 id 並按. 所有不經常訪問的 id 都應該駐留在一個大存檔表中，該存檔表仍然可以通過索引查找來訪問“藍月亮”查詢。
總體影響應該是至少有兩個分區：一個分區用於頻繁訪問的 id，另一個分區用於其餘 id。如果經常訪問的 id 的數量相當大，您可以選擇對其進行分區。