在同一RDS实例的多客户同结构MySQL库中创建/修改表的最佳实践

你当前采用的操作方式的行业定位 #

• 你目前的「自定义脚本遍历所有客户库、执行批量建表/变更语句」的做法，在租户规模数十家、所有库同实例部署的场景下，属于行业里常见的初期过渡方案，但不属于生产级的可靠通用实践。
• 这类纯手写的遍历脚本普遍存在几个天生的缺陷：没有执行状态追踪、没有异常隔离、没有版本校验，很容易出现漏执行某几个客户库、重复执行变更语句、部分库变更失败无感知的问题，随着客户数增长风险会快速升高。

更可靠、更安全的统一Schema变更方案 #

用成熟Schema迁移工具替代自研遍历脚本 #

• 完全可以基于标准化的开源Schema迁移工具（比如Flyway、Liquibase）做轻量适配，把所有客户库的连接配置统一纳入工具的管理范围，不用从零写遍历、执行、日志的全套逻辑：
  • 工具会自动为每个客户库记录当前的Schema版本号，能精准识别哪个库还没执行最新的变更脚本，从根源上避免漏库、重复执行的问题
  • 每一步变更都会做前置校验：比如建表前自动判断目标表是否存在、变更语句是否和当前库的现有结构冲突，从逻辑上避免执行报错
  • 全流程自动留存执行日志，执行完成后可以一键导出报告，明确列出来哪个库执行成功、哪个库执行失败、失败的具体原因，不用人工逐个登录库核对状态

搭建分层的变更防护流程 #

• 不要拿着写好的变更脚本直接跑生产，要加两层前置校验：
  • 预演校验：先在和生产环境配置完全一致的测试环境，模拟所有客户库的Schema状态，把全量变更脚本完整跑通，提前排查语法错误、兼容性问题
  • 干跑检查：正式执行前只做结构差异扫描，不实际执行变更语句，提前发现是否有客户库存在和基线不一致的自定义改动，避免批量执行的时候因为结构冲突中断
• 正式执行的时候做批次限流：不要一次性并发遍历所有客户库，按批次拆分执行节奏（比如每次处理5-10个库），同时所有DDL语句都要带存在性判断逻辑，比如使用CREATE TABLE IF NOT EXISTS、ALTER TABLE ... ADD COLUMN IF NOT EXISTS这类兼容语法，避免重复执行的时候直接报错。

加常态化的Schema一致性兜底 #

• 因为你所有客户库本来就要求Schema完全一致，可以搭一个轻量化的基线校验任务：定期扫描所有客户库的表结构、字段属性，一旦发现某个库的结构和官方基线版本有差异，立刻触发告警，不用等到做大版本变更的时候才发现库与库之间的结构差异。
• 把通用的表变更逻辑做成参数化模板：把需要创建的表结构、字段调整规则存在公共模板里，遍历执行的时候只需要传入目标库名参数，避免每次把完整的变更语句复制到脚本里，减少人为写错的概率。

现有自研脚本的常见避坑点 #

• 不要手写硬编码客户库名列表，直接从RDS的库清单接口自动拉取需要变更的库范围，避免新增客户库的时候没加到遍历名单里，出现新客户缺表的问题
• 所有执行操作必须留痕：脚本跑完后要把每一步的执行结果、执行时间、执行人记录到专门的审计表里，方便后续排查问题
• 提前准备回滚逻辑：每一个向前的Schema变更脚本，都要配套写好对应的回滚脚本，一旦批量执行出现大面积问题，可以快速把Schema恢复到之前的稳定版本

内容的提问来源于stack exchange，提问作者mcs