TRAE-AI编程
改表结构是 MySQL 日常运维里最高频也最容易出事的操作。本文用建表插样的最小示例，讲清 ADD COLUMN、MODIFY COLUMN 与 CHANGE COLUMN 三种写法的差别，重点说明它们对已有数据的影响和锁表风险。核心结论是：加列用 ADD，改类型用 MODIFY，同时改列名和类型才用 CHANGE，三者的不可混用之处集中在列名与类型这两项。下面每段都给出可直接执行的代码、预期输出和排错清单。先确认 MySQL 版本和表的数据量，再决定执行方式。
一、先看结论：三种写法怎么选
下面这张表给出三种语句的适用场景和注意点。判断顺序很直接：只想加一列用 ADD；类型不合适但列名不变用 MODIFY；要连列名一起改才用 CHANGE。
| 写法 | 适用场景 | 注意点 |
|---|---|---|
ADD COLUMN |
新增字段，如加备注列 | 不写 AFTER 就追加到表末尾，查询时容易漏 |
MODIFY COLUMN |
改类型或默认值，列名不变 | 必须把类型与约束写全，漏写会丢属性 |
CHANGE COLUMN |
同时改列名与类型 | 新旧列名都要写，漏写第二个会报错 |
需要提醒的是，MODIFY 与 CHANGE 都会重建表结构，在数据量大的表上会锁表，执行前必须确认业务低峰时间。想在线对比不同写法的执行结果，可用 在线代码实例 验证实际结果。
二、环境确认与最小示例
先建表插样，保证下面的每条语句都能对着真实数据验证。示例基于 MySQL 5.7 与 8.0，语法行为一致；8.0 对 ALTER 的原子性支持更好。以下为预期结果说明，未在本机执行，按 MySQL 官方文档推断。
# 进入 MySQL 命令行客户端
mysql -u root -p demo_db-- 建表：用户表，先只留最少的字段
CREATE TABLE users (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(20) NOT NULL,
phone VARCHAR(20)
);
-- 插入样例数据，便于验证修改后的筛选结果
INSERT INTO users (name, phone) VALUES
(\'张三\', \'13800000001\'),
(\'李四\', \'13800000002\');
建表之后先确认数据落库，再动手改结构。这一步的检查能避免后面用空表验证，得出错误结论。MySQL 版本差异对字段类型默认值的影响很小，但 AUTO_INCREMENT 在分库分表场景下的表现不同，属于要提前确认的边界。8.0 在在线改表方面做得更完善，细节可读 MySQL8 教程。
三、写法一：ADD COLUMN 新增字段
ADD 用于加列，不写位置就追加到表末尾。新列带 NOT NULL 时必须给默认值，否则已有行会因为缺值而失败。
-- 写法一：新增一列，放在 name 之后，业务上更符合阅读顺序
ALTER TABLE users
ADD COLUMN email VARCHAR(64) DEFAULT NULL AFTER name;
-- 新增 NOT NULL 列时必须给默认值，否则已有行会因缺值报错
ALTER TABLE users
ADD COLUMN age TINYINT NOT NULL DEFAULT 0 AFTER name;
AFTER name 决定新列的位置，省略就落到最后。判定标准是：加了列之后，业务查询是否需要调整字段顺序，需要就写 AFTER，不需要就省略。常见失败是给已有数据的大表加 NOT NULL 列却不给默认值，执行会中断，修复方案是补 DEFAULT 或先给可空列。
四、写法二：MODIFY COLUMN 改类型
MODIFY 改类型和约束，列名保持不变。写法上最容易出问题的地方是漏写约束：把 NOT NULL 改没了。
-- 写法二：把 phone 从 VARCHAR(20) 放宽到 VARCHAR(32)，列名不变
ALTER TABLE users
MODIFY COLUMN phone VARCHAR(32) DEFAULT NULL;
-- 反例：只写类型漏掉 NOT NULL，原有约束会被静默丢掉
ALTER TABLE users
MODIFY COLUMN name VARCHAR(30); -- name 原本写的是 NOT NULL，这句会丢掉
第二条语句是典型失败：约束丢失不会报错，但数据完整性已经变了。修复方向是改类型时把类型与约束一起写全，改完用 SHOW COLUMNS 核对一遍。这个检查必须做，因为静默丢约束比报错更危险。另一个容易忽略的点是被改列上的索引。把 VARCHAR(20) 放宽到 VARCHAR(32) 通常没事，但把带索引的列改小，MySQL 会直接拒绝执行；反过来把索引列类型改大，索引定义不会自动跟着调整，查询计划可能退化。改完用 SHOW INDEX 看一眼索引还在不在，比事后查慢查询省事得多。
五、写法三：CHANGE COLUMN 改名并改类型
CHANGE 同时处理列名和类型，新旧列名都要写。它是最容易写错语句的一种，因为少写一个名字就会语法报错。
-- 写法三：把 phone 改名为 contact，同时放宽长度
ALTER TABLE users
CHANGE COLUMN phone contact VARCHAR(32) DEFAULT NULL;
-- 只改列名、类型与原列一致，第二个名字照写原样即可
ALTER TABLE users
CHANGE COLUMN contact phone VARCHAR(32) DEFAULT NULL;改名之后，所有引用旧列名的查询都会失败，这类失败属于必然发生，需要在同一批次里一起改。排查清单按下面走：
| 现象 | 常见原因 | 修复方向 |
|---|---|---|
报 Duplicate column name |
新列名与已有列重名 | 确认目标列名，改名前先查现有字段列表 |
报 Unknown column |
用了旧列名，但列已被改名 | 同一批次里同步更新查询与代码中的字段名 |
| 加列时执行中断 | NOT NULL 列没给默认值，已有行缺值 |
补 DEFAULT，或先加可空列再回填 |
| 改类型后属性丢失 | MODIFY 漏写 NOT NULL 或默认值 |
类型与约束一起写全，改完核对表结构 |
| 大表执行卡住业务 | ALTER 期间锁表 |
放到低峰执行，或了解 8.0 的在线改表能力 |
以上失败与修复均来自真实边界场景，未在本机执行，按 MySQL 官方文档推断。想系统补齐 MySQL 基础，可以看 MySQL 教程。查字段默认值与约束时，建议顺手把这一句记进变更清单，避免下一次改列又漏写一遍。
总结
MySQL 修改表结构，按这三句话执行就不会错：加列用 ADD，注意 NOT NULL 必须给默认值、想控位置就写 AFTER；改类型用 MODIFY，类型和约束要一起写全，漏写会静默丢约束；要连列名一起改才用 CHANGE，两个名字都要写。执行前先确认 MySQL 版本和数据量，大表改结构会锁表，要放在业务低峰。改完用 SHOW COLUMNS 核对一次字段属性，这一步能挡住绝大多数静默丢属性的问题。
延伸学习
想在编程狮系统学 MySQL 表结构操作，可以顺着下面三篇深入：
常见问题
Q：ADD 和 MODIFY 能合并成一句吗？
A：不能。ADD 只负责新增列，列名必须不存在；MODIFY 只改已有列的定义。要同时改名和改类型，才需要用 CHANGE，语句里新旧两个列名都要写。
Q：MODIFY 时漏写 NOT NULL 会报错吗？
A：不会，约束会被静默丢掉。这类问题比报错危险，因为数据完整性已经被改变却没有痕迹。执行层面还有一条提醒：动手前先跑一次 SHOW CREATE TABLE 把完整定义抄出来，照着它把要保留的属性逐个写进新语句，比凭记忆补约束可靠得多。正确做法是改类型时把原有约束一起写进去，改完用 SHOW COLUMNS 核对字段定义。
Q：大表加字段会不会锁表？
A：会，尤其是对已有数据的大表。MySQL 5.7 及更早版本在执行期间锁表，8.0 提供了更完善的在线改表能力。无论哪个版本，都应放在业务低峰执行，并提前评估执行时长。
Q：改列名之后忘记改查询，会怎样？
A：会直接报 Unknown column。这类失败是必然发生且容易定位的，只要在同一批次里把所有引用旧列名的语句和代码一起更新即可，不要只改数据库那一侧。
