Liquibase管理PostgreSQL表：无停机批量数据替换及事务疑问

1. 不停机清除旧数据并添加新数据的可行方案 #

以下几种方案可实现服务不停机的全量数据替换：

• 影子表切换法：
  1. 创建与目标表结构（含索引、约束、权限）完全一致的新表；
  2. 将新数据批量导入新表；
  3. 执行原子性表名切换：ALTER TABLE table_name RENAME TO table_name_old; ALTER TABLE table_name_new RENAME TO table_name;；
  4. 验证服务正常读写新表后，再删除旧表。
     全程服务可持续读写旧表，切换瞬间无停机。
• 软删除+分批替换：
  1. 给目标表新增is_valid布尔字段，默认值true；
  2. 批量插入所有新数据并标记is_valid = true；
  3. 分批将旧数据更新为is_valid = false；
  4. 确认服务已过滤无效数据后，批量清理is_valid = false的记录。
     仅需修改服务查询逻辑过滤有效数据，全程无停机。
• 分区表交换：
  若目标表为PostgreSQL分区表：
  1. 创建与分区结构匹配的空表；
  2. 导入新数据到该空表；
  3. 执行ALTER TABLE table_name EXCHANGE PARTITION partition_old WITH TABLE new_table;完成分区交换；
  4. 验证后删除旧分区。
     交换操作是原子性的，不会阻塞服务读写。

2. 单事务执行TRUNCATE+批量插入的可行性 #

语法上可以执行，但完全不符合你「避免停机」的需求，核心问题：

• TRUNCATE会持有ACCESS EXCLUSIVE锁，且锁会一直持有到事务提交。30万条数据插入耗时3-4小时，这段时间内所有对该表的读写操作都会被阻塞，等同于服务停机。
• 单事务插入30万条数据会占用大量WAL日志和内存，拖慢数据库性能；一旦中途失败，回滚耗时也会极长。

3. 脚本执行期间其他查询的结果 #

在这个单事务执行过程中：

• 事务提交前，其他事务看不到任何修改，仍会读取表的原有数据——但前提是查询能在锁获取前执行完成。
• 由于TRUNCATE持有ACCESS EXCLUSIVE锁，所有后续对该表的读写操作都会被阻塞，处于等待状态，直到事务提交或回滚。

4. 脚本失败后的回滚情况 #

可以完全回滚到原有数据状态。PostgreSQL事务是原子性的，只要事务未提交，所有操作（包括TRUNCATE和批量插入）都会在事务失败时被撤销，表会恢复到事务开始前的状态。

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