本文沉淀多项目、多 schema、配置中心和 OA 同时变更时的通用执行方法，重点解决“目标库不明确、DDL 重复执行、配置和代码口径不一致、执行后没有读回验证”的问题。

1. 适用场景

  • 用户要求先在开发、测试或预发环境执行表结构变更。
  • 同一需求涉及 DGJ、Market、SAAS 或中心服务多个数据库。
  • 同一实例存在多个相似 schema 或同名表。
  • 本机缺少 MySQL CLI，需要使用已有安全连接工具。
  • 需求同时涉及 Apollo/配置中心、OA 模板或回调名单。

2. 标准流程

  1. 先读取该需求唯一的发布 runbook，列清 DB、配置、脚本、重启和验证范围。
  2. 从私有凭据仓读取已登记的连接项，只在进程内使用，不打印密码。
  3. 只读探测目标实例、schema、表、字段和索引。
  4. 将探测结果与代码模型、迁移文件和需求文档交叉确认。
  5. 不存在才执行幂等 DDL，且显式写 schema。
  6. 执行后从 information_schema 读回完整定义。
  7. 配置变更记录项目、namespace、key、用途、兼容窗口和回滚方式。
  8. 执行业务验证和日志检查，把脱敏结果更新到 runbook。

3. 常用只读 SQL

SELECT TABLE_SCHEMA, TABLE_NAME
FROM information_schema.TABLES
WHERE TABLE_NAME = '<table_name>';

SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, COLUMN_TYPE,
       IS_NULLABLE, COLUMN_DEFAULT, COLUMN_COMMENT
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = '<schema>'
  AND TABLE_NAME = '<table_name>'
  AND COLUMN_NAME = '<column_name>';

4. 容易踩坑

  • 同名表存在于其他 schema 不代表要一起改。
  • “字段不存在”与“当前账号看不到字段”要通过权限和 schema 双重确认。
  • zsh 的通配符未匹配会直接报错，查环境文件优先使用 find。
  • OA 提交模板、回调可处理模板和表单字段映射不是同一个配置。
  • 配置中心发布成功不等于应用已读取，要结合实例配置和业务日志验证。
  • 预发验证通过也不能替代生产风险评审。

5. 完成标准

  • runbook 中所有执行项有“已执行、无需执行、阻塞”之一的明确状态。
  • DDL 和配置均完成执行后读回。
  • 未误改相似 schema、无关项目或旧模板。
  • 文档只保留脱敏结论和凭据 key，不包含真实凭据与内网连接信息。