生产环境 SQL 变更须遵循“可预演、可验证、可回滚、有审批、有记录”五原则；变更前需需求确认与 SQL 评审，变更中实施灰度执行与实时监控，变更后完成效果验证与闭环归档，特殊场景须升级审批。
生产环境的 SQL 变更必须遵循严格的安全发布流程，核心原则是：可预演、可验证、可回滚、有审批、有记录 。任何未经评审和测试的直接执行，都可能引发 数据丢失、服务中断或性能雪崩。
变更前：需求确认与 SQL 评审
所有 SQL 变更（含建表、改字段、索引增删、大批量 UPDATE/DELETE）必须明确业务动因、影响范围和预期效果。禁止“先改后补说明”。关键动作包括：
- 由开发填写《SQL 变更申请单》，注明目标库表、SQL 语句、执行窗口期、回滚方案（如备份快照名或逆向 SQL）
- DBA 或资深 后端 进行 SQL 评审：检查是否含 隐式类型转换、未加 WHERE 条件、全表扫描风险、锁等待可能性（如 ALTER TABLE 在 MySQL 5.7 需锁表）
- 使用 pt-online-schema-change 或gh-ost等 工具 替代直接 ALTER，尤其在大表上
变更中：灰度执行与实时监控
禁止一次性全量执行。应按最小业务单元分批操作，并全程监控关键指标：
- 优先在从库或影子库预执行，验证语法、执行计划及耗时（EXPLAIN 分析）
- 主库执行时限定 QPS 或行数（如 UPDATE 加 LIMIT 1000，配合 WHERE 和索引），分批次提交
- 执行期间紧盯数据库 CPU、慢查询数量、连接数、复制延迟（Seconds_Behind_Master）、锁等待事件（information_schema.INNODB_TRX）
变更后：效果验证与闭环归档
执行完成不等于变更结束，必须验证结果并固化知识：
- 比对变更前后数据一致性（如 COUNT、SUM 校验；关键字段抽样核对）
- 观察应用日志是否有 SQL 报错、超时或降级；监控接口 P99 响应时间是否突增
- 将最终执行 SQL、执行人、时间、影响行数、验证结果、回滚记录统一归档至内部运维平台，保留至少 180 天
特殊场景强约束
以下操作必须升级审批且禁用自动化脚本：
- 删除表或清空表（TRUNCATE/DROP）：需 CTO 或技术负责人邮件确认
- 跨库关联 UPDATE/DELETE：须提供血缘影响分析报告
- 凌晨 00:00–06:00 操作：仅允许紧急故障修复，且需值班 DBA 双人复核 + 录屏
