直接结论:会加锁但扩大 VARCHAR 长度持锁时间极短毫秒级不会卡住业务。为什么扩大长度不重写表加锁(AccessExclusiveLock) → 改系统表元数据 → 释放锁整个过程毫秒级完成VARCHAR(n)的长度限制只是系统表里的一个数字底层存储和TEXT完全一样。PostgreSQL 只修改系统表 pg_attribute 中的 atttypmod 元数据不碰实际数据行上亿数据也几乎是秒级完成。不同操作对比操作重写表耗时VARCHAR 扩大长度❌ 不重写毫秒 ✅VARCHAR 缩小长度✅ 重写很慢 ❌改为其他类型INT等✅ 重写很慢 ❌改为 TEXT❌ 不重写毫秒 ✅什么情况会卡住不是 DDL 本身慢而是等锁排队表上有未提交的长事务 → ALTER 一直等后续所有查询全部堆积字段有函数索引 → 触发索引重建有 CHECK 约束 → 全表扫描重新验证生产环境必做-- 加锁超时保护超时自动退出不影响业务SETlock_timeout3s;ALTERTABLEbig_tableALTERCOLUMNyour_colTYPEVARCHAR(500);-- ✅ 3秒内完成 → 安全-- ❌ 报 timeout → 有长事务占锁换低峰期重试最稳方案AI 推荐我不推荐-- 第一步改为 TEXT毫秒完成不重写表ALTERTABLEbig_tableALTERCOLUMNyour_colTYPETEXT;-- 第二步加长度约束NOT VALID 跳过存量数据验证ALTERTABLEbig_tableADDCONSTRAINTchk_col_lenCHECK(char_length(your_col)500)NOTVALID;-- 第三步低峰期验证存量数据不阻塞读写ALTERTABLEbig_table VALIDATECONSTRAINTchk_col_len;一句话总结:扩大 VARCHAR 长度本身不重写表毫秒级完成 危险在于等锁期间请求堆积雪崩生产操作必须加 lock_timeout 保护最后推荐操作: 谁阻塞干谁-- 第一步找出阻塞方 查看谁在阻塞我的 ALTERSELECTblocking.pidAS阻塞方PID,blocking.queryAS阻塞方SQL,blocking.stateAS阻塞方状态,blocked.pidAS被阻塞PID,blocked.queryAS被阻塞SQL,now()-blocking.query_startAS阻塞持续时长FROMpg_stat_activity blockedJOINpg_stat_activity blockingONblocking.pidANY(pg_blocking_pids(blocked.pid))WHEREblocked.wait_event_typeLock;-- 第二步干掉阻塞方PIDSELECTpg_terminate_backend(阻塞方PID);-- 第二步重新执行ALTERTABLEyour_tableALTERCOLUMNyour_colTYPEVARCHAR(500);