发布检查单自动化（二）：数据库 DDL 变更前置扫描与兼容性校验-育师

发布检查单自动化（二）：数据库 DDL 变更前置扫描与兼容性校验

在微服务持续交付链路中，数据库 Schema 的破坏性变更一直是导致生产环境发布事故的高危诱因。诸如未添加默认值的非空字段新增、包含大量历史数据的全表锁表加列、索引修改导致的慢查询风暴以及删除正在被老版本应用读取的字段，极易引发线上雪崩。传统的 DBA 手工工单审批机制在每日数十次迭代的高频交付节奏下，不仅成了发布检查单上的吞吐瓶颈，还容易因人为疏漏漏判隐蔽的向后兼容性断裂。

为了将 Schema 治理防线彻底前移至代码合并阶段，我们在 CI 流水线中构建了基于 AST 解析与规则引擎的 DDL 自动化静态扫描与兼容性校验器。

DDL 扫描门禁的设计架构

自动化校验器挂载于 GitLab MR 的 Pipeline 阶段，当检测到项目中src/main/resources/db/migration/或专用 SQL 仓库发生变更时自动触发：

+------------------+ +-------------------+ +---------------------+ | GitLab MR Push | ---> | Flyway/Liquibase | ---> | SQL Parser (AST) | | (SQL File Diff) | | Version Sort | | & Grammar Validator| +------------------+ +-------------------+ +---------------------+ | v +------------------+ +-------------------+ +---------------------+ | MR Comment Bot / | <--- | Risk Evaluation | <--- | Compatibility Rules | | Pipeline Blocker | | (Block / Warning) | | Engine & Shadow DB | +------------------+ +-------------------+ +---------------------+

扫描流程分为三层检查：

语法与命名规范扫描：解析 SQL AST，校验主键规范、字符集（强制utf8mb4）、字段命名风格及注释完整度。
锁表与耗时风险评估（DCL/DDL 安全性）：拦截大表ALTER TABLE ... ADD COLUMN未指定ALGORITHM=INPLACE, LOCK=NONE等高风险行为。
应用向后兼容性契约校验：结合两阶段发布模型（Expand-Contract 模式），强制检查是否存在直接DROP COLUMN或修改已有字段类型的破坏性语句。

核心校验规则与 Go 实现

校验器核心采用 Go 编写，借助github.com/pingcap/tidb/pkg/parser提取 DDL 的抽象语法树，并注入企业自定义的安全规则集：

package ddlvalidator import ( "fmt" "strings" "github.com/pingcap/tidb/pkg/parser/ast" _ "github.com/pingcap/tidb/pkg/parser/test_driver" ) type SeverityLevel string const ( SeverityBlocker SeverityLevel = "BLOCKER" SeverityWarning SeverityLevel = "WARNING" ) type RuleViolation struct { RuleID string `json:"rule_id"` Severity SeverityLevel `json:"severity"` TableName string `json:"table_name"` Statement string `json:"statement"` Description string `json:"description"` Suggestion string `json:"suggestion"` } func ValidateAlterTableStmt(stmt *ast.AlterTableStmt, rawSQL string) []RuleViolation { var violations []RuleViolation tableName := stmt.Table.Name.O for _, spec := range stmt.Specs { switch spec.Tp { case ast.AlterTableDropColumn: // 规则 1：禁止直接删除字段（违反两阶段发布原则） violations = append(violations, RuleViolation{ RuleID: "DDL-COMPAT-001", Severity: SeverityBlocker, TableName: tableName, Statement: rawSQL, Description: fmt.Sprintf("表 [%s] 存在直接 DROP COLUMN 操作，破坏滚动发布向后兼容性", tableName), Suggestion: "遵循 Expand-Contract 模式：第一阶段下线业务引用并发布代码，第二阶段方可物理清理废弃列", }) case ast.AlterTableModifyColumn, ast.AlterTableChangeColumn: // 规则 2：禁止缩减字段长度或修改类型定义 colName := spec.NewColumns[0].Name.Name.O violations = append(violations, RuleViolation{ RuleID: "DDL-COMPAT-002", Severity: SeverityBlocker, TableName: tableName, Statement: rawSQL, Description: fmt.Sprintf("表 [%s] 的列 [%s] 发生 MODIFY/CHANGE 变更，存在类型不兼容与截断风险", tableName, colName), Suggestion: "请新增字段进行双写平滑迁移，严禁在活跃表上直接修改已有字段的数据类型", }) case ast.AlterTableAddColumns: for _, col := range spec.NewColumns { // 规则 3：新增 NOT NULL 字段必须显式指定 DEFAULT 值 hasNotNull := false hasDefault := false for _, opt := range col.Options { if opt.Tp == ast.ColumnOptionNotNull { hasNotNull = true } if opt.Tp == ast.ColumnOptionDefaultValue { hasDefault = true } } if hasNotNull && !hasDefault { violations = append(violations, RuleViolation{ RuleID: "DDL-RISK-003", Severity: SeverityBlocker, TableName: tableName, Statement: rawSQL, Description: fmt.Sprintf("表 [%s] 新增列 [%s] 设置了 NOT NULL 但未提供 DEFAULT 默认值", tableName, col.Name.Name.O), Suggestion: "新增非空字段必须赋予业务默认值，否则老版本代码插入数据将触发 SQL 异常", }) } } } } return violations }

影子库回放与元数据兼容性断言

单纯的 AST 静态语法检查无法感知目标数据库中的历史数据规模与依赖拓扑。我们在 CI 流程中引入了基于 Docker 的临时影子数据库（Shadow DB）：

#!/usr/bin/env bash set -eo pipefail TARGET_BRANCH="origin/main" CHANGED_SQL_FILES=$(git diff --name-only "$TARGET_BRANCH"...HEAD -- 'db/migrations/*.sql') if [ -z "$CHANGED_SQL_FILES" ]; then echo "未检测到 DDL 变更，跳过 Schema 前置校验。" exit 0 fi # 1. 启动轻量级临时 MySQL 容器 CONTAINER_ID=$(docker run -d -e MYSQL_ALLOW_EMPTY_PASSWORD=yes -p 33066:3306 mysql:8.0.36 --default-authentication-plugin=mysql_native_password) trap "docker rm -f $CONTAINER_ID > /dev/null 2>&1" EXIT # 等待 MySQL 准备就绪 until docker exec "$CONTAINER_ID" mysqladmin ping --silent; do sleep 1 done # 2. 导入当前生产基线元数据（脱敏后的 Schema 结构定义） docker exec -i "$CONTAINER_ID" mysql -u root < ./ci/baseline_schema.sql # 3. 逐个执行待合入的增量迁移脚本并捕获执行耗时与告警 for sql_file in $CHANGED_SQL_FILES; do echo "正在校验增量脚本: $sql_file" docker exec -i "$CONTAINER_ID" mysql -u root shadow_db < "$sql_file" done # 4. 运行 AST 静态规则拦截器 ddl-validator --input-dir="./db/migrations" --target-branch="$TARGET_BRANCH"