答复。

问题历史

随着敏捷方法的广泛应用，表结构的更改变得尤为重要。项目不断演进，需求也在变化——随着时间的推移，必然需要添加/更改/删除列。在生产数据库中，这些更改尤其风险很高。

问题

结构修改可能导致：

长时间锁定
丢失或迁移旧数据不正确
违反外部约束、触发器或应用逻辑

对于大型表（数百万行），尤其复杂，这些表被其他服务频繁使用。

解决方案

通过ALTER TABLE进行合理的分阶段操作、创建数据副本、在测试环境中测试、限制停机时间。使用事务、阶段性迁移和在大规模更改前进行备份。在高负荷的数据库管理系统中，通常使用“在线”ALTER算法。

示例代码：

-- 添加带默认值的新列
ALTER TABLE orders ADD COLUMN status VARCHAR(20) DEFAULT 'new';

-- 逐步填充新列
UPDATE orders SET status = CASE WHEN shipped_at IS NOT NULL THEN 'shipped' ELSE 'pending' END;

关键特性：

最好先创建新列，然后逐步迁移数据
大型操作应在非高峰时段进行
始终进行备份和自动测试

误导性问题。

ALTER TABLE是原子性操作吗？

通常不是：修改表可能需要很长时间。如果出现故障，部分更改可能会回滚，但部分更改会保留。因此，DDL命令的事务保护只是某些数据库（例如PostgreSQL）实现的。

可以无痛地将列类型从INTEGER更改为VARCHAR吗？

并不总是可以：如果列中有不符合新格式的旧数据或相关对象（索引、触发器、键），数据库可能不允许更改类型，或数据会被损坏。

ALTER TABLE总是对整个表施加排他锁吗？

这取决于数据库管理系统：在MySQL和旧版本的SQL Server中，任何ALTER操作通常会完全锁定表，直到完成，但现代数据库管理系统支持“在线DDL”，以减少锁定时间。

常见错误和反模式

在没有备份的情况下更改结构
在未测试的情况下迁移大型表
在没有检查依赖关系的情况下重命名列（例如，外键、过程）
在高峰时段进行批量ALTER操作

实际案例

负面案例

DevOps工程师通过ALTER TABLE对三个重要表进行了批量更改并删除了旧列。没有考虑到这些列链接了外键和触发器。在执行ALTER期间，数据库占用20分钟——在此期间，由于缺少所需的字段，服务“宕机”。

优点：

更改按照技术需求实施

缺点：

部分服务失去可用性
业务停顿近半小时
依赖关系恢复和删除数据的恢复工作量大

正面案例

分析师计划分阶段添加列：首先创建带默认值的列，在副本上进行测试负载，然后才在夜间进行实际的ALTER，并通知所有开发者即将进行的迁移窗口。