Partitioning
對一個非常大的表進行分區，還是拆分為多個表？
我們有一個足夠老的 MySQL 伺服器沒有啟用分區，所以我們決定使用我們最大的表並將所有舊行移動到另一個表。如果在某個時候需要它們，它們將被移動到“最近的表”，以使其使用更快。總的來說，這意味著我們將擁有：
- table_old：持有大約 25Gb
- table_recent : 持有大約 1Gb
我們將永遠保持這個比例，試圖平衡舊數據與新數據的數量，並在最近的數據中只保留上週使用的數據。
事實證明，以乾淨的方式開發有點困難，但現在執行良好。通過僅編輯“最近日期”門檻值，我們可以平衡最近表將保存多少數據。在某些時候，舊行會轉到舊表，如果需要一些舊數據，則會事先將其移動。
現在，我們遷移到 MySQL 5.7，分區是一回事。在開發人員方面它看起來更乾淨，但我不知道它是否會像我們現在所擁有的那樣高效，這意味著我們可以更新一行的last_used_time欄位並將其彈出到主表中。
- 如果我的分區基於這樣的可變欄位，MySQL 還會在分區之間移動這些欄位嗎？
- 分區表會使系統執行得更快，還是將數據保存在不同的表中更好？
我懷疑任何人都可以告訴你，你自己開發的系統的性能會比 MySQL 內置分區的性能更好還是更差。
總的來說，一些想法：
- 使用 MySQL 的分區，您將獲得任何改進的好處，只需升級到更新的版本；在大多數情況下，您的程式碼可能不需要更改。
- MySQL 的分區可能會為您已經做的事情提供更大的靈活性，使今天不切實際的一些事情能夠充分發揮作用。
- 您必須自己支持您自己開發的版本，並使其與系統的其他更改一起使用。
- 您自己開發的版本（大概）完全按照您的需要工作，並且與您的其他應用程序一起工作得很好。
- 如果您有特殊需要，您可以選擇修改自己的系統；雖然修改 MySQL 是可能的，但它涉及的更多。
- 要將您目前的系統移動到 MySQL 的分區可能需要在您的系統中進行一些程式碼更改，並且可能需要調整多個查詢（以避免遇到不必要的分區）。
所以：
- 測試將您的表切換到 MySQL 分區可能是值得的，以了解它如何處理您的數據（切換並看到主要的性能下降將是一件壞事）。
- 從長遠來看，您可能希望嘗試切換到使用 MySQL 的分區（因為它可能會隨著時間的推移而變得更好，並且維護您的解決方案可能會隨著時間的推移變得更加複雜）……
- …除非事實證明您的本地解決方案的某些功能在 MySQL 分區中不存在並且對您的應用程序至關重要。
- 在任何情況下，我都願意在切換到 MySQL 分區上花費至少與開發和完善自己的解決方案所花費的時間和精力一樣多的時間和精力。它可能要簡單得多，但您可能無意中圍繞您的解決方案建構了系統的其他部分，這些部分必須重新設計才能與 MySQL 分區一起使用。
這都是完全通用的建議——我對 MySQL 分區（或者你的解決方案，就此而言）一無所知。不過，我已經建立了一些系統，我們在其中創建了自己的解決方案，而不是使用現有產品。我知道有時它們可以更好地滿足您的需求 - 但它們確實需要維護，並且切換到使用不太適合您的具體情況的工具最終可以為您節省維護時間，但可能會在靈活性方面花費您，並且可能需要同時了解以及您了解您的解決方案。
如果您的解決方案維護成本低並且對您很有效，並且沒有重大的性能問題，那麼我至少現在傾向於維護它。但是，考慮到探索的時間以及現在可能有一個與您所擁有的一樣好或更好的內置解決方案這一事實，我想檢查一下它是否適合您。