ALTER TABLE操作需谨慎：ADD COLUMN要指定DEFAULT和位置；MODIFY/CHANGE COLUMN可能触发重建；DROP COLUMN影响索引和依赖；RENAME TABLE需权限且不覆盖。线上大表务必测试锁表现与依赖链。
添加字段用 ADD COLUMN，注意默认值和位置
添加新列最常用，但容易忽略 DEFAULT 和 AFTER/FIRST 子句。不设默认值时，如果表非空，MySQL 会为旧记录填入隐式默认值（如 0、''、NULL），可能引发数据歧义。
- 加非空字段必须指定
DEFAULT，否则报错：ALTER TABLE users ADD COLUMN status TINYINT DEFAULT 1;
- 想插到某列之后：用
AFTER col_name；插到最前：用FIRST - MySQL 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(*) 估数据量，最后在测试库跑一遍完整流程。