先解答第一个问题：为啥ALTER COLUMN varchar(255) TYPE text会触发全表重写？ #

在PostgreSQL 9.1里，哪怕varchar(255)和text的底层存储逻辑几乎一致（对于长度≤255的字符串，存储格式完全相同），但数据库会把修改列数据类型这个操作视为「需要彻底更新每一行的元数据和数据」的重量级操作。

原因是PG的类型系统要求，当列类型变更时，必须确保每一行的该列数据都被显式转换为新类型——哪怕这个转换在逻辑上只是“换个标签”，数据库也会强制扫描全表的每一行，重新序列化并写入整行数据（因为行的类型标记已经改变）。这个过程中，数据库会给表加上ACCESS EXCLUSIVE锁（最高级别的排他锁），在锁持有的期间，任何读写该表的操作都会被阻塞，直到全表重写完成。

再看分步方案的本质区别 #

那位资深开发者的方案，核心是把一个全表级的重型操作，拆解成多个轻量、低锁影响的步骤，完全规避了全表重写和长时间锁表：

• 第一步：新增text列
  ALTER TABLE your_table ADD COLUMN new_text_col text;
  这个操作只修改系统表（表的元数据），不需要触碰任何现有行数据，锁表时间只有元数据变更的一瞬间，几乎不会影响业务的正常读写。

• 第二步：分批同步数据
  比如用分批更新的方式：UPDATE your_table SET new_text_col = old_varchar_col WHERE id BETWEEN 1 AND 1000;，或者用SELECT ... FOR UPDATE锁定单行后更新。这个过程中只有被操作的行会被加上行级锁，其他行完全可以正常读写，不会出现全表阻塞的情况。而且可以根据数据库负载调整分批的大小，避免一次性给数据库带来过大压力。

• 第三步：删除旧列
  ALTER TABLE your_table DROP COLUMN old_varchar_col;
  同样只修改元数据，标记旧列不再被使用，锁时间极短。旧列占用的存储空间会由后台的VACUUM操作异步回收，完全不影响业务。

本质区别总结 #

• 直接ALTER COLUMN是一次性的全表范围的元数据+数据强同步操作：数据库必须保证整个表的所有行都完成类型转换，所以强制全表扫描重写，加全表排他锁。
• 分步方案是将数据变更拆解为逐行/分批的行级操作：所有元数据变更都是轻量瞬间完成，数据同步只影响局部行，从根源上避免了全表锁和全表重写，把对业务的影响降到了最低。

另外补充一句：在PostgreSQL 12及以后的版本，官方优化了部分类型转换的逻辑（比如varchar转text这类无实质数据变化的转换），不需要再全表重写，但9.1版本确实没有这个优化，所以这个分步方案在你的场景里是非常稳妥的选择。

内容的提问来源于stack exchange，提问作者code0079