3. 数据库变更类型分类

在变更窗口内执行数据库变更，是数据库可靠性保障的核心场景。不同类型的变更，其风险特征、执行策略、回滚方案和监控粒度存在显著差异。将变更按类型进行系统化分类，是设计可靠性服务目录的基础。本章将变更划分为五大类：DDL变更、DML变更、配置变更、架构变更和版本升级变更。

3.1 五大变更类型总览

下表从变更对象、风险等级、典型操作、回滚难度和推荐窗口五个维度，对五大变更类型进行横向对比。

3.2 DDL变更（数据定义语言）

DDL变更直接修改数据库对象的元数据，是变更窗口中最常见且风险最高的操作之一。其核心风险在于：表级锁、索引重建IO消耗、元数据锁（MDL）阻塞。

• 典型场景：新增字段、修改字段类型、添加索引、删除索引、修改表引擎。
• 可靠性要点：
  • 优先使用 ONLINE DDL（如MySQL的 ALGORITHM=INPLACE）减少锁表时间。
  • 大表DDL必须拆分执行，或使用工具（如gh-ost、pt-online-schema-change）进行无锁变更。
  • 变更前必须备份元数据（SHOW CREATE TABLE），变更后立即验证表结构。
• 回滚策略：DDL回滚通常需要反向执行（如删除新增字段），大表回滚耗时与正向变更相当，需提前评估。

-- 示例：安全的在线DDL（MySQL 8.0+）
ALTER TABLE orders 
ADD COLUMN discount DECIMAL(5,2) DEFAULT 0.00,
ALGORITHM=INPLACE, 
LOCK=NONE;

3.3 DML变更（数据操作语言）

DML变更直接影响业务数据，虽然不修改表结构，但大范围数据操作可能导致事务阻塞、主从延迟、数据不一致。

• 典型场景：批量数据修正、历史数据清理、数据迁移、状态更新。
• 可靠性要点：
  • 批量DML必须分批执行，每批控制在1000~5000行，避免长事务。
  • 变更前必须备份受影响数据（SELECT INTO OUTFILE 或创建备份表）。
  • 使用 LIMIT 和 WHERE 精确控制影响范围，禁止无过滤条件的全表UPDATE/DELETE。
• 回滚策略：提前生成逆向SQL脚本（如UPDATE的反向SET语句），并验证回滚脚本的正确性。

-- 示例：分批DML变更（每次更新5000行）
UPDATE orders 
SET status = 'archived' 
WHERE status = 'expired' AND create_date < '2023-01-01'
LIMIT 5000;

3.4 配置变更

配置变更通常被认为风险较低，但不当的配置修改可能导致性能骤降、连接风暴甚至实例重启。

• 典型场景：修改缓冲区大小（innodb_buffer_pool_size）、调整连接数（max_connections）、开启/关闭慢查询日志、修改字符集。
• 可靠性要点：
  • 区分动态参数（可在线修改）和静态参数（需重启生效），静态参数变更必须纳入窗口管理。
  • 修改前记录当前参数值，修改后观察监控指标（QPS、连接数、锁等待）。
  • 配置变更应遵循小步修改原则，每次只改1~2个参数，便于定位问题。
• 回滚策略：直接恢复为原参数值，静态参数需重启实例，需提前评估重启影响。

3.5 架构变更

架构变更是最高风险的变更类型，涉及数据库拓扑结构的调整，一旦失败可能导致全站不可用或数据分裂。

• 典型场景：主从切换、读写分离调整、分库分表（Sharding）、增加/移除节点、复制链路调整。
• 可靠性要点：
  • 架构变更必须提前演练，在预发环境或灰度集群中验证流程。
  • 变更前必须全量备份，并确保binlog完整可用。
  • 主从切换必须使用自动化工具（如Orchestrator、MHA），避免人工误操作。
  • 分库分表变更需考虑数据迁移一致性和路由规则平滑切换。
• 回滚策略：架构变更的回滚通常需要逆向操作（如切回原主库），且必须在变更前准备好回滚脚本和验证方案。

3.6 版本升级变更

版本升级变更涉及数据库内核或大版本的替换，是变更窗口中最复杂、耗时最长的操作。其核心挑战在于兼容性和性能回归。

• 典型场景：MySQL 5.7 升级到 8.0、PostgreSQL 12 升级到 14、安全补丁安装、小版本更新。
• 可靠性要点：
  • 升级前必须进行兼容性评估（SQL语法、数据类型、系统变量、插件兼容性）。
  • 必须搭建升级验证环境，使用生产流量回放或压测工具验证性能。
  • 大版本升级推荐使用逻辑复制或滚动升级方案，减少停机时间。
  • 升级后需执行回归测试，包括功能测试、性能测试和稳定性测试。
• 回滚策略：版本升级回滚通常需要全量恢复（从备份重建实例），或使用逻辑复制反向同步。回滚时间窗口需提前规划。

3.7 变更类型与可靠性服务映射

下图展示了五大变更类型与可靠性服务目录中关键服务项的映射关系，帮助运维团队快速定位每类变更所需的可靠性保障能力。

3.8 变更类型选择决策树

在实际变更窗口操作中，运维人员可通过以下决策树快速判断变更类型，并匹配对应的可靠性服务。

1. 是否修改数据库对象定义？
   • 是 → DDL变更（需灰度发布、回滚预案）
   • 否 → 进入下一步
2. 是否修改数据行内容？
   • 是 → DML变更（需分批执行、数据备份）
   • 否 → 进入下一步
3. 是否修改数据库参数或设置？
   • 是 → 配置变更（需区分动态/静态参数）
   • 否 → 进入下一步
4. 是否修改拓扑或节点关系？
   • 是 → 架构变更（需演练、全量备份）
   • 否 → 进入下一步
5. 是否替换数据库软件版本？
   • 是 → 版本升级变更（需兼容性评估、回归测试）
   • 否 → 不属于标准变更类型，需人工评估