共計 2500 個字符，預計需要花費 7 分鐘才能閱讀完成。
這篇文章主要講解了“怎么理解 MyCAT 中的 DDL”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“怎么理解 MyCAT 中的 DDL”吧！
今天開發同學提了一個需求，是希望對某一個時間范圍的表做 DDL 操作，看起來好像復雜度也不高。
但是我一看開發同學提供的信息時就有點猶豫了，因為端口是 8066，也就意味著使用了中間件。這是一套 MyCAT 的環境，一共有 4 個節點，每個節點拆分成了 4 個邏輯節點，所以有 16 個 sharding 分片，正是應了那句話：百庫十表。雖然目前看起來節點數也不多，但是看看這個表 hisrecord 的分片邏輯就會發現，遠遠比我們想的要更豐富一些。
這個表是按照日期來存儲數據的，即數據的存儲單位是日。表名類似于 rec20180301，rec20180302 這種。所以按照這種增長的趨勢，可以根據時間維度不斷擴展，同時又對每天的表做了細粒度的拆分，每個日表會有 16 個分片做 hashl 路由。
開發同學的需求是對某一天之后的日表添加字段，變更第一天的數據需要對該字段添加默認值，之后的就不需要默認值了，這個從業務的角度來說，是因為應用層升級，需要這個屬性，如果有些業務暫時還沒有遷移過來，有一天的時間來緩沖調整修復。所以目前的需求的福利就是我們要修改的表目前沒有寫入，做變更不用考慮在線業務的寫入影響。
我簡單算了下，按照目前的修改幅度，影響的日表有 177 個。
mysql select datediff(2018-11-01 , 2018-05-08
+————————————-+
| datediff(2018-11-01 , 2018-05-08) |
+————————————-+
| 177 |
+————————————-+
1 row in set (0.00 sec)
按照 16 個分片來算，這個數量就相當大了，有 2800 多張表。
mysql select 177*16;
+——–+
| 177*16 |
+——–+
| 2832 |
+——–+
1 row in set (0.00 sec)
涉及的 DDL 表有 2 個，即 2 個 DDL 語句，所以算下來就是 5600 多張表了。所以你看一張表就能拆分成 2000 多張表，一年有差不多 5800 張相關的表。
如果在這個基礎上考慮當天的表結構變更，那就更復雜了。
我們來簡單看下 MyCAT 里面的 schema.xml 配置。
里面配置了 16 個分片，即 dn50-dn65,database 是 histrecord01-histrecord16
dataNode name= dn50 dataHost= localhost1 database= hisrecord01 /
dataNode name= dn51 dataHost= localhost1 database= hisrecord02 /
。。。
dataNode name= dn65 dataHost= localhost4 database= hisrecord16 /
對表的分片規則是按照 hash 取模來計算的。
table name= rec20180301 dataNode= dn$50-65 rule= mod-long-16-pid /
table name= rec20180302 dataNode= dn$50-65 rule= mod-long-16-pid /。。。
table name= rec20180307 dataNode= dn$50-65 rule= mod-long-16-pid /
要做這個工作，手工完成的可能性太低，所以準備了如下的腳本，借鑒了之前同事的一些思路。
我們輸入兩個時間，即起始時間，終止時間。app_sql/create_sql.sql 是表結構的定義文件。這個腳本的意義在于不斷的處理表結構信息，打上時間戳，寫入另外一個腳本文件，按照日期循環 100 天，就寫入 100 次。
startdate=`date -d 20180508 +%Y%m%d`
enddate=`date -d 20181101 +%Y%m%d`
#定義循環主函數
function main(){
while [[${startdate} ${enddate} ]]
do
echo ${startdate}
cat /home/mysql/app_sql/create_sql.sql /home/mysql/app_sql/alter_his_record.sql
sed -i s/20180508/${startdate}/g /home/mysql/app_sql/alter_his_record.sql
echo /home/mysql/app_sql/alter_his_record.sql
echo
startdate=`date -d +1 day ${startdate} +%Y%m%d`
done
}
#執行主函數
main
所以很快就完成了上述的基本操作。當然 MyCAT 端是不支持 DDL 語句的。所以我們需要在每個節點上單獨去執行相應的變更 DDL。
根據得到的腳本略作改動，就可以分發到不同的 sharding 節點側了。整個過程持續了不到半個小時，很多時間都是在不斷的確認中，因為這個變更的影響范圍確實有點大。
當然這個問題的前提是我們已經創建好了日表，如果沒有日表的話，我們還是需要重新配置一下，然后在 MyCAT 端 reload 一些配置。
把這個任務擴展一下，就會發現，中間件層面的數據處理更側重于 TP 業務，而且是插入密集型的業務，如果是節點間的交互分布式，那這個方案就不大適合了。同時不斷的拆分從業務的角度來說，歷史數據的歸檔保留和數據的聚合需求還是有的。可能在這個時候中間件層面的支持就很有限了，我們在一定程度上可能需要其他的解決方案。
感謝各位的閱讀，以上就是“怎么理解 MyCAT 中的 DDL”的內容了，經過本文的學習后，相信大家對怎么理解 MyCAT 中的 DDL 這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
