PostgreSQL大表DDL需避免锁表，应优先使用CONCURRENTLY创建/删除索引，分步添加带默认值列，避免表重写；通过pg_repack或逻辑复制实现在线变更，结合锁监控与低峰操作，确保平滑执行。
在 PostgreSQL 中对大表执行 DDL（数据定义语言）操作时，锁表是一个常见且棘手的问题。很多 DDL 操作会获取 ACCESS EXCLUSIVE 锁，导致表在执行期间无法被读写，影响线上业务的可用性。为了避免长时间锁表，可以采用一些在线 DDL 技巧和策略。
1. 利用支持并发执行的 DDL 语法
PostgreSQL 提供了一些 DDL 命令的“并发”版本，可以在不阻塞读写的情况下完成操作：
- 添加列并设置默认值时使用 AFTER COMMIT 或 DEFAULT 延迟处理：直接添加带默认值的列会重写整个表。可以先添加 NULL 默认值的列，再通过 UPDATE 分批填充，避免长事务。
- 创建索引时使用 CONCURRENTLY： CREATE INDEX CONCURRENTLY idx_name ON table(column); 这样不会阻塞写操作，但执行时间更长，且失败时不会生成损坏索引（需手动清理）。
- 删除索引也建议使用 CONCURRENTLY：DROP INDEX CONCURRENTLY 避免短时锁表。
2. 避免重写表的操作
某些 DDL 会导致全表重写，从而引发长时间锁和 I/O 压力：
- 不要直接修改列类型（ALTER COLUMN TYPE）：这会触发表重写。可考虑新增兼容字段，逐步迁移数据，最后切换应用逻辑。
- 重命名列或表是轻量级操作：RENAME 不涉及数据变动，几乎无锁。
- 添加非空列需谨慎：如果带 NOT NULL 和 DEFAULT，PostgreSQL 9.6+ 会优化为快速添加（不重写），但旧版本仍可能重写表。
3. 使用扩展工具辅助大表变更
对于真正的大表（TB 级别），可借助外部工具实现零停机变更：
- pg\_repack：通过重建表的方式在线整理表和索引，无需 ACCESS EXCLUSIVE 锁。适合 VACUUM FULL 或表结构调整。
- 逻辑复制 + 表切换：新建结构变更后的表，通过逻辑复制同步数据，验证后原子切换（重命名），最小化停机时间。
- 使用 gh-ost / pt-online-schema-change 思路（配合 PostgreSQL 逻辑复制）：虽然原生工具面向 MySQL，但类似原理可在 PG 上自建流程。
4. 观察锁状态与执行时机控制
即使使用安全命令，也要监控锁情况：
- 查询 pg_locks 和 pg_stat_activity 判断是否有冲突事务。
- 避免在高峰期执行 DDL，选择低峰时段。
- 使用事务包装 DDL 并设置锁超时：
SET lock_timeout = '30s';
BEGIN;
ALTER TABLE ...;
COMMIT; 防止长期阻塞其他查询。
基本上就这些。关键在于理解每个 DDL 的锁级别，优先使用 CONCURRENTLY、避免重写表，并结合工具和流程设计实现平滑变更。合理规划，大表 DDL 也能做到近乎无感。
