批量数据库变更
今天聊一聊数据库多地域部署，以及分库分表架构下，数据库变更的挑战。
想象一家国际化的电商企业，在不同地区拥有庞大的用户群体，覆盖了欧美、亚洲等多个国家的市场。那么可想而知，这家企业拥有的数据量是难以统计的。自然而然的，企业综合业务访问速度、业务连续性保障、跨部门协同以及业务独立性等因素考量，将数据库进行了多环境、多地域部署。
由于业务的相关性，对于数据库的变更往往涉及多个分布在不同数据源中的库和表，为了不影响业务，这些变更需要确保同步进行。例如下述几个场景：
企业决定进行一次全球性的产品分类重构，需要对产品数据库中的分类结构进行大规模的调整。考虑到全球各个地域的数据库分布，企业需要在全球范围内同步更新产品分类信息，以避免用户在不同地区看到不一致的产品分类。
为了分散数据库读写压力，提升性能，企业将业务数据库进行了水平拆分，分成了多个库和表。而此时，需要对该业务库增加一个字段，以应对新产品迭代的需求。
作为一个 DBA，你将如何应对这种情况呢？笔者觉得会有以下几种：
所有数据库逐个变更：最传统的方法，人肉一个一个数据库挨个变更。麻烦不说，耗时贼长，数据源多的情况下难免漏掉个一两个数据源，导致某几个地域的数据分类不一致，后期写入新数据的情况下可能会导致业务报错。
SQL 变更脚本：通过 SQL 脚本在所有数据源中执行，相比逐个变更的方法效率更高，但是为了保证结果完整，在变更完成后需要手动挨个查询校验变更结果，并且如果 SQL 脚本有问题没检查出来，等到变更在所有数据源中执行之后...
上述两种方法可能是上述场景下被使用得最多的方法了，然而缺点自然也是不言而喻的，对于频繁需要对多个数据库做相同变更的企业来说，简直就是下下策。
那么什么才是上策？
问得好！曾几何时，你为了保证线上业务连续性，彻夜加班到天亮，那个时候，你难道就没有幻想过只用一个 SQL 语句就能在所有数据源中完成执行？又或者，只提交一个 SQL 任务，就能让系统在规定的时间自动执行，免去加班到半夜的困扰。
其实，只需要通过 NineData 的库表分组功能，结合 SQL 任务，就能轻松实现这些效果。
简单演示下配置方法
创建库分组，将需要批量进行变更的数据库加入到一个分组中。
提交 SQL 任务，选择该库分组，执行 DDL 语句，为该分组中所有库中的
departments表新增一个列。
SQL 任务审批通过后，变更语句将在该库分组的所有库中执行，可以在 SQL 任务的详情页确认每个库中的执行结果。
打开 SQL 窗口，验证执行结果。
