最近，領導發話了，要處理數據量很大的表，提前規避因數據量大而導致，查詢、更新操作緩慢的問題。
數據量很大的表，我看了下，最多的records表，2400w條記錄。
拉上DBA，一起斷斷續續的討論了一個多星期，確定了方案(還不是最終方案，哎，跨部門協作，效率是真低)
前前後後討論了四種方案，這裏記錄一下心路歷程。
1.分區 - 時間
最初是DBA提出的分區方案，分區鍵是時間。然後，我提供了時間字段，就坐等完工了。心裏還美滋滋的想，哇，這次的任務好輕鬆啊！哪知道，是我太年輕了。
臨上線之前，DBA把所有的東西都找我確認一下。然後，我發現一個很奇怪的事情，他把我提供的時間，加到 唯一鍵裏了。
WTF！ 本來是三個字段來約束唯一的，你加上 時間，那不就違背了之前的邏輯了嗎？果斷否了！
然後，DBA解釋道：分區鍵，必須要在唯一約束裏面，分區後，主鍵就不能保證唯一了。比如：分成兩個區了，就是兩個local，mysql的id只能保證local內的唯一。所以，分區後的唯一，就依賴唯一鍵了。
我聽了，好像挺有道理的哈。但是，違背了原邏輯，還是得否啊。
這裏插兩句
1.mysql中，一個表，只允許擁有一個唯一鍵。所以，搞兩個唯一鍵，一個保持原邏輯，一個加上時間，這樣是不行的。
2.分區後，程序裏的sql需要帶上 分區鍵，也就是那個時間。不然，mysql不知道你應該查哪個分區，sql會在所有的分區都執行一遍，多次IO。
2.分區 - 數據量
前面說的，按時間維度來分區，行不通。我想了一下，能否根據數據量來分，比如，1-500w記錄，在分區一；500w-1000w記錄，在分區二。
結果，DBA給我否了。理由是，他們不好管理維護。。。
不好維護？我去，哪裏不好維護了？再問人家，他居然不鳥我了。。。
後來我查了下，假如用id作爲分區鍵，用戶表，2000w數據，4個分區。如果分區一，也就是用戶id 1-500w的，非常活躍，查詢大部分都是查他們。那麼會造成邏輯上的數據不均衡，失去了分區的意義
按照時間維度，數據相對會更加均衡。並且若想按照時間進行數據歸檔，則只需要對某一個分區數據進行歸檔即可。所以，網上基本上也是推薦根據時間去分區的。
3.分表方案
這是DBA腦抽想出來的。
DBA希望有幾個月份，就有幾張表。現狀是一張表records，按照他的想法，會有4張表，records_202001、records_202002、records_202003、records_202004。這不是扯淡嗎，那代碼裏得改多少地方啊，果斷否了
4.數據定時遷移
最終，DBA提議數據遷移：每個月或者每個季度，把一年前的數據，遷移到備份庫，然後把原表的數據刪掉。
這樣的話，代碼不需要改動，如果業務一定要看一年之前的數據，那我們只需要再部署一套代碼，把數據源配置改爲備份庫即可。
定時遷移方案，會出什麼問題呢？目測沒問題，不過，這一切只有等真正實施後纔會知道。