MySQL中的拆分錶。好習慣？
我已經開始處理一個現有項目，之前的開發人員將一個表拆分為 10 個獨立的表，這些表具有相同的架構但不同的數據。
表格如下所示：
[tableName_0] [tableName_1] [tableName_2] [tableName_3] [tableName_4] [tableName_5] [tableName_6] [tableName_7] [tableName_8] [tableName_9]主鍵是一個整數
id欄位。該應用程序使用散列算法 (idmod 10) 來了解在進行查找時要訪問的表。例如id= 10 將導致[tableName_0].結合起來，這些表可能有 100,000 行，並且增長率相對較低。
所以，我的問題是這是否是一個可行的解決方案，或者即使它在任何情況下都是一個好習慣。我的理論是推動將它們結合起來，因為它會使事情變得更容易，就
UNIONs等而言。主要缺點是更改所有應用程式碼以及從長遠來看是否值得。
我認為每個人都過於復雜了。這裡的關鍵點是：
結合起來，這些表可能有 100,000 行，並且增長率相對較低。
這對於任何 RDBMS 來說 *都是小菜一碟。*使用一張表，正確索引它，並將其視為已解決的問題。
您不需要考慮分區，無論是“自製”還是其他，直到您開始處理大量數據——想想數十億行甚至更多。
您可以使用合併表，但是它們在 4.x 版本中已經過時了。鑑於您的應用程序是手動分區的，因為它要麼是 a) 您執行的是一個非常舊的版本，要麼 b) 原始開發人員不知道表分區。
簡而言之，如果你執行的是 5.1+，你可以讓 mysql 為你做這個分區。請參閱 http://dev.mysql.com/doc/refman/5.1/en/partitioning.html 如果您使用的是 5.5，您應該檢查那些特定的文件，因為您會發現一些差異。
分區有很多優點。然而，這實際上取決於手頭的數據集、訪問模式以及如何對其進行索引。另外，請記住我的以下評論是在 mysql 5+ 分區的上下文中，而不是較舊的 mysql Merge 表；儘管它們有時會根據分區進行討論。
一些例子：
- 基於經常訪問的查找鍵的直接分桶（或散列）。如果您幾乎總是通過主鍵或其他唯一鍵查找，那麼 mysql 可以根據您擁有的分區數量來減少搜尋空間。但是請注意，如果您按一個鍵分區，然後經常按另一個鍵搜尋，這可能是有害的。如果您通過鍵搜尋數據未分區，那麼它必須對查找進行更多搜尋（每個分區一個，b / c坦率地說，它不知道數據在哪裡）
- 考慮以下情況：您有一組按日期增長的時間記錄，並且您定期刪除上個月。如果您按日期分區，那麼您可以簡單地刪除一個分區，它與刪除一個表一樣快，無論多大。如果您要按日期修剪這樣的表，則必鬚髮出一個或多個 DELETE 查詢，其中每一行都被刪除。這樣做的缺點是，一旦您達到了在這種情況下考慮的最大日期，mysql 就不會自動創建新分區；您需要額外的維護腳本來根據需要添加分區。
- 如果您使用 myisam 檢查和恢復更快。考慮一個 100G myisam 表。如果你想恢復一個崩潰的表，你至少需要大約 100G 的備用磁碟空間。如果它被劃分為 10 個大小相同的不同塊，那麼您只需要 10G 的空間（以及更少的 key_sort_buffer 記憶體以實現快速恢復）；但需要對每個分區進行迭代。
所以總而言之，分區表的一般方法可以提供許多好處。但是，如果不考慮訪問模式以及分區的精確程度，盲目地應用它並不是靈丹妙藥。
我可以想像所需分區非常特定於應用程序的情況，並且更適合將該邏輯放在應用程序層中。但是，鑑於您的直接模數 10 描述，這似乎不是這種情況。
編輯
在寫我的描述時，我忘記了你說你的表是 100K 行。如果沒有表的完整架構和平均行長度，很難確定，但總的來說，即使對於適度的硬體，這聽起來也是中等大小。同時，如果它沒有像現在或在可預見的將來那樣造成問題，那麼不要花時間通過改變它來引入風險。