为什么在 PostgreSQL 表中间添加一列如此困难
在 PostgreSQL 中，无法直接在表的中间位置添加新列，这是因为 PostgreSQL 的存储引擎基于堆存储模型，列的顺序由表定义中的属性编号决定。任何试图在中间插入列的操作都需要重建整个表，这对大型生产数据库来说代价极高。文章深入分析了 PostgreSQL 的存储架构、元组布局以及为何无法像 MySQL 那样支持 AFTER 子句添加列，并给出了几种实用的替代方案，如重建表、使用视图或调整列排序策略。
背景速读
- PostgreSQL（简称 PG）是世界上最流行的开源关系型数据库之一，以稳定和功能丰富著称。它采用堆存储（heap storage）和 MVCC（多版本并发控制）机制，这意味着更新数据时不会原地覆盖，而是写入新版本——这直接影响了表结构变更（schema migration）的实现方式。
- 在数据库表中“中间插入一列”看似简单，但在 PostgreSQL 里却非常困难。原因是 PG 的数据行是物理上连续存储的，列的顺序由表定义（catalog）决定；如果强行在已有数据中间插入新列，几乎需要重写整张表。
- 主流数据库对此做法各异：MySQL 的 InnoDB 允许指定列的物理位置（AFTER 关键字），但代价是隐式重建表；SQLite 直到 2021 年之前连“删除列”都做不到；而 PG 的设计哲学更偏向在末尾追加列，再通过视图（VIEW）调整逻辑顺序，不动底层物理存储。
- 本文作者来自 Bytebase，一家做数据库变更管理和 CI/CD 工具的公司，所以对 schema migration 的痛点有切身理解。文章也暗示了为什么像 ORM 框架（如 Rails 的 ActiveRecord）和迁移工具通常默认把新列加在末尾——不是偷懒，而是底层数据库就是这么设计的。