生产环境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双人复核+录屏
