這是學習筆記的第 2085 篇文章
對于周期表的生命周期管理，一直以來是一個不被重視的環節，聽起來有些拗口，所謂的周期表就是類似日表分區表那樣的資料表，在MySQL中我們和業務方算是達成了共識，把需求引導過來後，需求如雨後春筍一般都冒出來了，是以在管理中也發現了很多的潛在問題。
建表需求是一種第風險操作，而删除則是高風險操作，是以在處理方式上兩者的方式就有很大的差别，比如建立周期表，我們可以提前一兩周就預建立1個月~3個月的周期表。
而删除操作則是滞後的處理方式，首先我們想盡可能多的保留資料的曆史資訊，同時又要考慮存儲情況盡可能物盡其用，在這方面能夠做到的隻能是平衡，而為了盡可能不出錯，我們總是采取保守的方式，導緻資料庫立面的周期表越來越多。
建立的工作相對可控，但是删除的操作就麻煩了，我們需要謹慎處理，為了保證drop操作的可控和可回溯，我們設定了資源回收筒的處理方式，即一個資料庫會對應一個arch命名的歸檔庫，當我們要删除周期表時，可以把要删除的表rename到arch命名的歸檔庫裡面，資料表在歸檔庫裡面，但是對于業務來說，資料是不可見的，效果跟删除了資料是相似的。
我這邊設計了4個狀态來追溯整個生命周期的一些階段，籠統來說，是分為兩個階段。
第一階段是轉置，做rename操作，把表資料歸檔到arch歸檔庫裡面。
第二階段是清理，做drop操作，在arch歸檔庫開始删除操作，删除的頻率不宜過于頻繁。
在開始階段，我們需要做的就是根據邏輯去提取過期的周期表。
在這個基礎之上應用上面4個狀态，比如表不存在，環境配置的差異導緻rename操作失敗，會把整個操作的失敗之處都記錄下來，而rename成功就會是狀态MOVE_ARCH_SUCC,而提取，轉置工作完成之後，就可以開始資料清理了。一般來說在清理的過程中，我們需要增加一系列的校驗規則，比如對周期表的屬性進行檢查，確定操作完全可靠，可控。
在使用了如上的設計思路之後，完成這個功能還是很快的，在掃描了大量的環境之後，我們轉置了7000多張表（狀态MOVE_ARCH_SUCC）,而CLEAN_ARCH_FAIL和MOVE_ARCH_FAIL的場景都基本上是因為人工幹預導緻操作失敗。
而清理展開之後，一下子就清理了幾十套環境的7000多張表。
