📚 课程目录第4章数据库表结构变更影响

4. 数据库表结构变更影响：新增/删除字段、修改类型、修改默认值、索引变更

表结构变更，说白了就是动数据库的「骨架」。我见过太多线上事故，起因就是随手加了个字段，或者改了个类型。你想想看，生产环境跑着几百个服务，你这边一改表结构，那边查询可能就崩了。

这一章，咱们把最常见的四种变更拆开揉碎了讲。我会结合自己踩过的坑，告诉你每个操作背后到底有什么风险。

4.1 新增字段：看似无害，实则暗藏杀机

很多人觉得加字段是最安全的操作。嗯，大部分情况确实如此，但有几个细节你一定要注意。

  核心原则：新增字段时，如果该字段有 NOT NULL 约束且没有默认值，会导致已有数据行写入失败。

举个例子，你有一张用户表，里面有 1000 万行数据。现在你要加一个 age 字段：

-- 危险操作
ALTER TABLE users ADD COLUMN age INT NOT NULL;

-- 安全操作
ALTER TABLE users ADD COLUMN age INT NULL;
-- 或者
ALTER TABLE users ADD COLUMN age INT NOT NULL DEFAULT 0;

为什么第一个写法危险？因为 MySQL 在 5.6 之前，加 NOT NULL 字段会锁全表，逐行写入默认值。1000 万行数据，锁表时间可能长达几分钟。我当年在电商公司就吃过这个亏，大促前加了个字段，结果导致订单写入超时，直接影响了半小时的交易量。

我的建议：生产环境新增字段，优先使用 NULL 允许，或者指定明确的 DEFAULT 值。如果必须用 NOT NULL，可以考虑用 pt-online-schema-change 这类工具做在线变更。

4.2 删除字段：你以为删的是字段，其实删的是业务

删除字段比新增危险得多。新增最多是报错，删除可能直接丢数据。

我见过最离谱的事故：某团队删了一个叫 status 的字段，结果下游有 5 个定时任务都在读这个字段。删除操作执行后，所有任务全部报错，数据对账停了整整两天。

删除字段前，你必须确认三件事：

代码层面：所有服务中是否还有对该字段的读写操作？
数据层面：历史数据是否还有引用？比如报表、归档、备份。
依赖层面：是否有触发器、存储过程、视图依赖这个字段？

避坑指南：我曾经建议团队用「软删除」策略——先把字段标记为废弃，观察至少一个完整业务周期（比如一周），确认没有报错后再物理删除。这个习惯救过我们好几次。

4.3 修改字段类型：最容易被低估的风险

改字段类型，说白了就是给数据库「换心脏」。稍有不慎，整个系统都可能停摆。

咱们来看几种常见场景：

原类型	新类型	风险等级	说明
INT	BIGINT	低	范围扩大，数据安全，但会锁表重建
VARCHAR(50)	VARCHAR(100)	低	长度增加，一般安全
VARCHAR(100)	VARCHAR(50)	高	可能截断数据，直接丢内容
VARCHAR	INT	极高	非数字字符直接转换失败
DATETIME	TIMESTAMP	中	范围缩小，2038年问题

我印象最深的一次事故：有个同事把订单金额字段从 DECIMAL(10,2) 改成了 DECIMAL(8,2)，结果所有超过 100 万的订单金额全部被截断。财务对账时发现少了 200 多万，查了半天才发现是字段精度不够。

我的经验：改字段类型前，先跑一遍 SELECT 查询，看看现有数据是否都在新类型的范围内。比如改 VARCHAR 为 INT，先查有没有非数字字符：

SELECT * FROM orders WHERE amount REGEXP '[^0-9]';

4.4 修改字段默认值：看似简单，实则影响写入路径

改默认值不会动已有数据，但会影响新插入的数据。这个操作本身很快，但风险在于「业务逻辑的隐性依赖」。

举个例子：

-- 原默认值
ALTER TABLE users ALTER COLUMN status SET DEFAULT 'active';

-- 改为
ALTER TABLE users ALTER COLUMN status SET DEFAULT 'inactive';

这个改动本身只需要毫秒级时间。但问题来了——如果某个服务在插入数据时没有显式指定 status 字段，它就会拿到 inactive。新注册的用户全部变成非活跃状态，登录直接被拦截。

我曾经踩过的坑：有一次我们改了订单状态的默认值，从 pending 改成 draft。结果所有通过 API 创建订单的服务，因为没有显式传状态字段，全部生成了草稿订单。运营同学第二天发现订单量暴跌 80%，差点报警。

所以我的习惯是：改默认值之前，先查一下代码仓库里所有 INSERT 语句，看看哪些地方没有显式指定这个字段。

4.5 索引变更：查询加速器还是性能杀手？

索引变更是个双刃剑。加对了，查询飞起；加错了，写入卡死。

咱们先看几种常见索引变更的影响：

操作	对读的影响	对写的影响	锁表风险
新增索引	查询加速	写入变慢（维护索引）	MySQL 5.6 前锁表
删除索引	查询可能变慢	写入变快	几乎无锁
修改索引	取决于新索引	重建期间影响写入	高
新增唯一索引	查询加速	写入需检查唯一性	中（需扫描重复）

我特别想强调一点：新增唯一索引前，一定要先检查数据是否有重复。

-- 先检查重复
SELECT email, COUNT(*) 
FROM users 
GROUP BY email 
HAVING COUNT(*) > 1;

-- 确认无重复后再加唯一索引
ALTER TABLE users ADD UNIQUE INDEX idx_email (email);

如果直接加唯一索引，而数据里有重复值，整个 ALTER 操作会直接失败。更坑的是，在 MySQL 5.7 之前，这个操作会锁表，你连查都查不了。

  我的建议：生产环境加索引，优先用 CREATE INDEX 而不是 ALTER TABLE。前者在 MySQL 8.0 中支持在线 DDL，对业务影响更小。另外，加索引最好选在业务低峰期，比如凌晨 2-4 点。

4.6 一张图看懂表结构变更影响

下面这张图，我把四种变更的核心影响路径画出来了。你可以把它当作「变更前的检查清单」。

4.7 总结一下

表结构变更没有「安全」的操作。每个变更背后，都藏着数据、代码、性能三个维度的风险。

我个人习惯是：任何变更前，先写一份影响分析文档。哪怕只有几句话，也要把「改了哪里、影响谁、怎么回滚」写清楚。这个习惯帮我避免过至少 10 次线上事故。

最后送你一句话：数据库变更，慢就是快。多花 10 分钟做影响分析，可能省下 10 小时的故障排查时间。