如何對mysql表進行分區
我有一個設計糟糕的表，並且最重要的是列數正在增加（〜500），因為每次發現新機器時。（例如：路由器，適配器Windows伺服器等）..它將儲存我們之後的命令輸出發現由後端處理的機器。
例如：我們發現一個在機器上執行的 docker。我們將獲得容器和圖像詳細資訊….將它們作為藍圖及其屬性保存在表格中，並帶有適當的列；
表包含 100 萬條記錄。我們經常做連接，因為這個特定的表是我們的主表。至於現在規範化數據庫是不可行的，任何人都可以給出解決方法或任何建議（如分區或分片）。Thanxin提前..如果您需要更多詳細資訊，請發表評論
我認為你應該從不同的角度分析這個場景，因為看起來很可能 (a) 繼續使用相關表的目前結構可能最終會 (b)遠不如(c) 在所有相應的層，即：
- 概念（建模和定義$$ i $$表格所代表的事物的類型和$$ ii $$所述類型的事物所涉及的業務上下文的相應規則$$ ii $$適當的精度）；
- 邏輯（用新的規範化元素和準確的數據類型反映數據庫結構中感興趣的事物的類型，並設置適當的約束以使包含的數據符合相關的業務規則）；和
- 物理（根據確切的數據操作趨勢建立適當的索引策略，安裝更強大的硬體，可能是分區和分片，升級網路頻寬等）抽象級別。
保持目前的表結構（約 500 列！）需要以非有效的方式接近它（操作和管理等），如果您預計數據量會大幅增長，那麼系統的擴展性將非常差並且可能無法操作。在 (3) 重大重組中使用 (1) 全部精力用於 (2) 處理這種非最佳情況可能會好得多。
當然，表格的某些目前方面很可能以後可以重用（例如，非常有價值的數據，可能需要清理），但我肯定會考慮重新排列——至少部分地，在主要熱點- 上面提到的所有因素，而不是提出實際上是姑息的變通辦法。遲到總比不到好。
您必須咬緊牙關，對數據集進行重大改造。
500 列是站不住腳的，必須是改造的一部分。閱讀這篇文章，了解如何不這樣做，以及使用 JSON 作為替代方案的建議。有一些獲取和過濾所需的資訊列；將大多數列放入單個 JSON 列中。
想想你需要什麼查詢。這在決定哪些列要分開並由 MySQL 而不是應用程序輕鬆處理時很重要。
一百萬行對於分片來說太小了
PARTITIONing。您對數據集的描述不足以說明是否將多個表（一個用於容器，一個用於伺服器等）連結在一起，以及是否有很多標準化的機會等。
如果目前“列”的某些子集是“可選的”，則“垂直分區”（具有公共 PK 的兩個表）可能是一個選項。