数据库改个字段而已，为什么总能把线上系统搞崩？

ALTER TABLE user_info
ADD COLUMN phone VARCHAR(20);

修改表结构
    ↓
发布代码
    ↓
完成

旧代码 ───────┐
              ├──→ 数据库
新代码 ───────┘

CREATE TABLE user_info (
    id BIGINT PRIMARY KEY,
    name VARCHAR(50)
);

ALTER TABLE user_info
ADD COLUMN phone VARCHAR(20) NOT NULL;

INSERT INTO user_info(id, name)
VALUES (1001, '张三');

API v1
API v2

Schema v1
Schema v2

phone

ALTER TABLE user_info
ADD phone VARCHAR(20) NOT NULL;

ALTER TABLE user_info
ADD phone VARCHAR(20) NULL;

INSERT INTO user_info(id, name)
VALUES (1001, '张三');

SELECT id, name, phone
FROM user_info;

数据库：
┌────────────────────┐
│ id                 │
│ name               │
│ phone              │ ← 新字段
└────────────────────┘

旧代码 → 只认识 id/name
新代码 → 认识 id/name/phone

1000 万用户

UPDATE user_info
SET phone = 'xxx';

UPDATE user_info
SET phone = ...
WHERE id > 100000
  AND id <= 110000;

10万
10万
10万
10万
...

UPDATE user_info
SET phone = ...;

输入 SQL
↓
执行 SQL
↓
返回结果

这张表有多大？
当前 QPS 多高？
有没有长事务？
有没有锁等待？
当前连接数多少？
这个 SQL 会不会锁表？
执行预计影响多少行？
当前是不是业务高峰？
失败以后怎么回滚？

ALTER TABLE orders
ADD COLUMN delivery_address VARCHAR(500);

表名：orders
数据量：1.2 亿

当前 QPS：8600

活跃事务：37

长事务：2

数据库负载：72%

DDL 风险：中

建议：
❌ 当前不建议执行

username

user_name

ALTER TABLE user_info
CHANGE username user_name VARCHAR(50);

SELECT username
FROM user_info;

ALTER TABLE user_info
ADD COLUMN user_name VARCHAR(50);

写 username
写 user_name

user.setUsername(username);
user.setUserName(username);

String name = user.getUserName();

if (name == null) {
    name = user.getUsername();
}

旧代码
    ↓
username

新代码
    ↓
user_name

数据逐渐完成迁移

ALTER TABLE user_info
ADD COLUMN user_name VARCHAR(50);

username
   ↓
┌───────────────┐
│ username      │
│ user_name     │
└───────────────┘

UPDATE user_info
SET user_name = username
WHERE user_name IS NULL
LIMIT 10000;

读取 user_name
写入 user_name

username ← 不再使用

ALTER TABLE user_info
DROP COLUMN username;

ALTER TABLE user_info
DROP COLUMN old_field;

user.getOldField();

Unknown column 'old_field'

ADD

DROP
RENAME
TYPE CHANGE

ADD COLUMN       → 低风险
ADD INDEX        → 中风险
MODIFY COLUMN    → 高风险
DROP COLUMN      → 极高风险
RENAME COLUMN    → 极高风险

SELECT *
FROM orders
WHERE user_id = 10001;

CREATE INDEX idx_user_id
ON orders(user_id);

SQL 是 CREATE INDEX
↓
执行

CREATE INDEX
↓
检查数据库类型
↓
检查版本
↓
检查表规模
↓
检查当前负载
↓
判断是否支持 Online DDL
↓
生成执行计划
↓
执行
↓
监控

ALTER TABLE orders
ADD INDEX idx_user_id(user_id),
ALGORITHM=INPLACE,
LOCK=NONE;

ALTER TABLE big_table
MODIFY COLUMN amount DECIMAL(10,2);

表数据量：8.7 亿

当前 QPS：12000

数据库 CPU：82%

存在长事务：3

DDL 类型：字段类型修改

风险等级：高

正在执行……

❌ 拒绝自动执行

原因：
1. 超大表
2. 高峰期
3. 字段类型发生变化
4. 存在长事务

建议：
低峰期执行
或采用在线 Schema 变更工具

Git
 │
 ├── application
 │
 └── migrations
        │
        ↓
   Schema Analyzer
        │
        ↓
   Compatibility Check
        │
        ↓
   Risk Assessment
        │
        ├── LOW ─────→ 自动执行
        │
        ├── MEDIUM ──→ 人工审批
        │
        └── HIGH ────→ 禁止自动执行
                         │
                         ↓
                       DBA

db/
├── V001__create_user.sql
├── V002__add_phone.sql
├── V003__add_user_name.sql
└── V004__create_user_index.sql

“谁在生产库上手工改了什么？”

“Git 里记录了这次 Schema 演进。”

开发人员
    ↓
Navicat
    ↓
生产数据库

Git
 ↓
Review
 ↓
自动检查
 ↓
审批
 ↓
执行

ADD COLUMN

MODIFY COLUMN

DROP COLUMN

旧代码 + 新 Schema

新代码 + 旧 Schema

UPDATE 1亿条数据;

分批
 ↓
限速
 ↓
监控
 ↓
异常暂停
 ↓
继续

LOW
 └── ADD NULL COLUMN

MEDIUM
 └── ADD INDEX

HIGH
 ├── MODIFY COLUMN
 ├── RENAME COLUMN
 └── 大表 DDL

CRITICAL
 └── DROP COLUMN

数据库是基础设施
代码依赖数据库
数据库由 DBA 管

代码的一部分

版本管理
自动检测
兼容性分析
灰度发布
风险控制
审计
监控
回滚策略