共计 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 小编将为大家推送更多相关知识点的文章，欢迎关注！
