添加字段用 ADD COLUMN，注意默认值和位置
添加新列最常用，但容易忽略
DEFAULT和
AFTER/
FIRST子句。不设默认值时，如果表非空，MySQL 会为旧记录填入隐式默认值（如
0、
''、
NULL），可能引发数据歧义。 加非空字段必须指定
DEFAULT，否则报错：
ALTER TABLE users ADD COLUMN status TINYINT DEFAULT 1;想插到某列之后：用
AFTER col_name；插到最前：用
FIRSTMySQL 8.0+ 支持
AFTER，但早期版本（如 5.7）只支持
FIRST或不指定位置（默认追加末尾） 线上大表慎用——
ADD COLUMN在多数 MySQL 版本中仍会锁表（除非启用
ALGORITHM=INPLACE且满足条件）
修改字段类型或名称用 MODIFY COLUMN / CHANGE COLUMN
MODIFY COLUMN只改类型/约束，不改名；
CHANGE COLUMN必须写两次列名（原名 + 新名），可同时改名和类型。两者都可能触发全表重建，尤其当类型变更涉及字符集、精度或是否允许 NULL 时。 仅改类型（比如扩大长度）：
ALTER TABLE logs MODIFY COLUMN message VARCHAR(2000);同时改名和类型：
ALTER TABLE orders CHANGE COLUMN user_id customer_id BIGINT NOT NULL;把
TEXT改成
VARCHAR(500)？不行——MySQL 不允许降级为更小的变长类型，会报错
ER_TOO_LONG_KEY或直接拒绝 从
NOT NULL改成
NULL通常安全；反过来则要求该列当前无
NULL值，否则失败
删除字段用 DROP COLUMN，不可逆且影响索引
DROP COLUMN看似简单，但实际风险集中在依赖关系上：外键、视图、存储过程、应用代码里硬编码的字段引用都会失效。 基本语法：
ALTER TABLE products DROP COLUMN discontinued_at;若该列是复合索引的一部分，整个索引会被自动删掉（MySQL 不会智能保留剩余字段的索引） 有外键指向该列？先
DROP FOREIGN KEY，再删字段；否则报错
ER_FK_COLUMN_CANNOT_CHANGE已上线服务中删除字段前，务必确认所有读写逻辑已下线该字段——ORM 映射、SELECT *、INSERT ... VALUES(...) 都可能崩
重命名表用 RENAME TO，注意跨库和权限
看起来最轻量的操作，其实暗藏路径陷阱。MySQL 的
RENAME TABLE实质是原子性文件系统重命名，速度极快，但对目标库和权限有硬性要求。 同一库内重命名：
RENAME TABLE old_users TO users;跨库移动表（本质是重命名+迁移）：
RENAME TABLE db1.users TO db2.users;要求当前用户对两个库都有
DROP和
CREATE权限 目标表名已存在？操作直接失败，不会覆盖——必须先确认目标名未被占用 使用了 MyISAM 引擎？重命名期间表不可读写；InnoDB 则基本无感知，但仍建议避开高峰 真实环境里最常翻车的不是语法，而是没评估锁表现和依赖链。一个
ALTER TABLE在百万行表上执行几分钟，可能让下游监控报警炸锅；而删掉一个看似“没用”的字段，可能让某个三年前写的报表 SQL 突然返回空结果。动手前，先
SHOW CREATE TABLE看结构，再
SELECT COUNT(*)估数据量，最后在测试库跑一遍完整流程。
