4. 变更窗口分类与适用场景：常规维护窗口、大版本升级窗口、紧急热修复窗口、灰度发布窗口

变更窗口（Change Window）是数据库变更管理的时间边界与策略约束。不同类型的变更对停机容忍度、回滚复杂度、验证周期要求截然不同。将变更窗口按风险与操作性质分类，是实施分层回滚策略的前提。本章详细定义四类核心窗口的适用场景、操作特征与回滚约束。

4.1 四类变更窗口总览

4.2 常规维护窗口

定义：在预定义的业务低峰期（如凌晨 02:00–04:00）执行的计划性变更，包括索引重建、统计信息更新、表结构微调、配置参数修改等。

适用场景

• DDL 变更（加列、改类型、加索引）
• DML 批量数据清理或归档
• 数据库参数动态调整（需重启实例的参数除外）
• 慢查询优化后的索引部署

回滚策略

• 前置条件：变更前必须生成 REVERSE 脚本（如 ALTER TABLE … DROP COLUMN 对应 ADD COLUMN）。
• 验证方式：先在预发布环境执行完整变更 + 回滚，记录耗时。
• 失败处理：窗口内若超时或报错，立即执行回滚脚本，无需人工审批。

-- 常规窗口回滚脚本示例（MySQL）
-- 正向：增加分区
ALTER TABLE orders PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025)
);

-- 反向：移除分区（回滚）
ALTER TABLE orders REMOVE PARTITIONING;

4.3 大版本升级窗口

定义：涉及数据库内核版本跨越（如 MySQL 5.7 → 8.0、PostgreSQL 12 → 16）的重大变更，通常需要完整的停机计划、数据校验与全量回退预案。

适用场景

• 数据库大版本升级（含操作系统兼容性变更）
• 存储引擎替换（如 MyISAM → InnoDB 批量转换）
• 集群架构重构（主从 → 分布式、单节点 → 集群）
• 字符集或排序规则全局变更

回滚策略

• 必须保留完整快照：升级前做全量物理备份 + binlog 位点记录。
• 回滚方式：只能通过重建实例 + 全量恢复 + 增量回放完成，不支持脚本级逆向。
• 验证周期：升级后至少观察 24 小时业务流量，确认无隐性问题后方可释放旧实例。

4.4 紧急热修复窗口

定义：针对生产环境 P0/P1 级故障（如数据损坏、连接池耗尽、死锁风暴）的即时变更窗口，要求变更在分钟级内完成，且对用户影响控制在秒级闪断以内。

适用场景

• 紧急 Kill 阻塞会话或终止长事务
• 临时调整连接数、超时参数
• 修复因 Bug 导致的错误数据（如 UPDATE 误操作后的紧急回滚）
• 热加载配置或路由规则

回滚策略

• 热回滚：变更本身必须是可逆的，且回滚操作不依赖复杂脚本。例如：SET GLOBAL max_connections=500 回滚为 SET GLOBAL max_connections=200。
• 变更记录：所有热修复操作必须实时记录到变更审计表，事后补全审批单。
• 禁止场景：DDL 操作（如加列、删表）严禁在紧急窗口执行，必须降级为常规窗口。

-- 紧急热修复示例：临时调大连接池
-- 正向
SET GLOBAL max_connections = 1000;
-- 回滚（热回滚）
SET GLOBAL max_connections = 200;

4.5 灰度发布窗口

定义：通过流量路由、读写分离或影子表机制，将变更逐步暴露给部分用户或部分数据库实例，持续验证无问题后再全量推送。灰度窗口没有固定结束时间，而是以“验证通过”为关闭条件。

适用场景

• 表结构变更（加列、改类型）对存量数据兼容性不确定
• 索引变更对查询计划影响未知
• 存储过程或函数逻辑重写
• 数据库中间件或代理层配置变更

回滚策略

• 流量摘除：灰度实例一旦出现错误，立即从负载均衡中摘除，将流量切回旧实例。
• 数据回滚：灰度期间写入的数据必须可回退（如通过影子表 + 同步延迟对比）。
• 渐进比例：建议按 1% → 5% → 20% → 100% 的流量比例逐步放量，每个阶段至少观察 30 分钟。

4.6 窗口选择决策流程

4.7 窗口分类与回滚分层映射

每种变更窗口对应不同的回滚层级，这是本课程后续章节的核心映射关系：