alter table rename column在mysql 8.0+中不重写数据，仅需短时sx元数据锁，但会阻塞select for update等操作；postgresql同理，但新增default非null列仍可能触发全表扫描。
ALTER TABLE RENAME COLUMN 会锁表吗？
在 MySQL 8.0+ 和 PostgreSQL 中，RENAME COLUMN 是原子操作且基本不锁表（仅需短时元数据锁），但实际是否“不停机”取决于存储引擎和并发负载。MySQL 的 InnoDB 在执行 ALTER TABLE ... RENAME COLUMN 时仍会获取 S（共享）元数据锁，阻塞后续的 DML 直到语句完成——对大表来说，这个“完成”可能只是毫秒级，但若前面有长事务未提交，它就会卡住，表现为应用写入超时。
而 SQLite、SQL Server（2016+）或 Oracle 的 RENAME COLUMN 同样不重写数据，但 SQL Server 需要 ALTER TABLE ... ALTER COLUMN ... 配合 sp_rename 才能真正改名，单独用后者只改系统视图，应用层查询旧名仍能命中（但属“伪重命名”，不推荐）。
关键判断：只要数据库版本支持原生命名语法，且没有阻塞它的长事务，RENAME COLUMN 本身不是瓶颈；真正的风险来自后续的数据迁移。
如何安全迁移存量数据而不锁表？
字段重命名常伴随类型变更或逻辑调整（比如把 user_name 改为 full_name 并转为非空），此时不能只靠 RENAME COLUMN，必须迁移数据。直接 UPDATE 大表必然锁行甚至锁表，应避免。
推荐分三步渐进式迁移：
- 新增目标字段（如
full_name），允许 NULL，不加索引 - 用小批量异步任务填充数据（每次
UPDATE ... LIMIT 1000，间隔 100ms），避开业务高峰；同时用触发器或应用双写，确保新写入同步到新字段 - 校验一致性（例如
SELECT COUNT(*) FROM t WHERE user_name != full_name），确认无误后，再DROP COLUMN user_name
注意：PostgreSQL 的 pg_cron 或 MySQL 的事件调度器可驱动批量任务，但更稳妥的是用外部脚本（Python + mysql-connector）控制节奏，便于监控和中断恢复。
MySQL 5.7 怎么绕过不支持 RENAME COLUMN 的限制？
MySQL 5.7 不支持 RENAME COLUMN 语法，常见错误是直接写 ALTER TABLE t CHANGE user_name full_name VARCHAR(100)——这会重建整张表，对百 GB 表等于停机数小时。
正确做法是模拟“轻量重命名”：
- 先
ALTER TABLE t ADD COLUMN full_name VARCHAR(100) AFTER user_name（不锁表） - 启动双写（应用层同时写
user_name和full_name） - 跑离线迁移补全历史数据（同上小批量）
- 切换读取逻辑指向
full_name，最后删旧字段
整个过程不依赖 CHANGE COLUMN，规避了隐式 COPY 算法。如果必须用 CHANGE，务必确认表上有 ALGORITHM=INPLACE 且 LOCK=NONE（仅部分场景支持，需查官方文档对应版本的限制表）。
为什么不能跳过双写直接切读？
因为字段迁移不是原子的：新字段上线、数据补全、应用切换读取，三者时间点必然错开。如果跳过双写，只等数据补全后再切读，那在补全期间新插入的记录 full_name 为空，导致业务读到空值或报错。
双写本质是用写放大换读一致性。容易被忽略的一点是：触发器双写在高并发下可能成为性能拐点（尤其跨库或含复杂逻辑时），此时应优先在应用层实现，而非依赖数据库触发器。
另外，所有迁移步骤都必须配 WHERE 条件过滤已处理行（如 WHERE full_name IS NULL），否则重复执行脚本会引发主键冲突或覆盖脏数据。
