一、核心原理为什么数据能恢复​ 在 PostgreSQL 中执行 DELETE 操作后数据并不会立即从磁盘上物理擦除。PostgreSQL 使用多版本并发控制MVCC机制删除操作仅仅是给数据行打上了一个“已删除”的标记在事务 ID 层面标记为 xmax。只有当 VACUUM自动清理或手动清理进程运行并扫描该表时这些被标记为“已删除”的物理空间才会被真正回收和覆盖。因此恢复的关键在于与 VACUUM 进程赛跑。二、紧急止损黄金三步一旦发现误删必须立即执行以下操作以锁定现场防止数据被彻底清理。立即停止应用写入防止新数据写入覆盖掉被标记为删除的旧数据页。禁用自动清理这是最关键的一步。必须针对受影响的表关闭 autovacuum。-- 将 your_table_name 替换为实际表名 ALTER TABLE your_table_name SET (autovacuum_enabled false);​ 3.锁定表防止其他会话对表进行操作确保数据文件处于静止状态。BEGIN; LOCK TABLE your_table_name IN ACCESS EXCLUSIVE MODE; -- 保持事务开启不要提交或回滚直到恢复完成三、恢复方案 A使用 pg_dirtyread 插件推荐如果数据库允许安装扩展这是最安全、最直观的方法。该插件允许用户读取被标记为删除但仍存在于磁盘上的“脏”数据。安装插件需在目标数据库中执行需超级用户权限CREATE EXTENSION pg_dirtyread;2.查询被删数据使用插件提供的函数读取数据。你需要明确指定表的字段结构。SELECT * FROM pg_dirtyread(your_table_name) AS t(id int, name text, create_time timestamp) -- 必须与表结构一致 WHERE (SELECT pg_xact_commit_timestamp(xmax)) IS NOT NULL; -- 筛选被删除的行xmax表示删除该行的事务 ID。如果 xmax 不为 0说明该行已被删除。pg_xact_commit_timestamp(xmax)可选用于查看删除发生的时间。​ 3.数据回写确认查询到的数据无误后将其插回原表或新表。INSERT INTO your_table_name (id, name, create_time) SELECT id, name, create_time FROM pg_dirtyread(your_table_name) AS t(id int, name text, create_time timestamp) WHERE (SELECT pg_xact_commit_timestamp(xmax)) IS NOT NULL;四、恢复方案 B底层十六进制解析硬核方案如果无法安装插件可以通过查询底层页面数据来手动还原。PostgreSQL 将数据存储在 8KB 的页面中heap_page_items函数可以读取页面的原始字节流。获取原始数据查询被删除行的十六进制数据。SELECT lp, t_attrs FROM heap_page_item_attrs(get_raw_page(your_table_name, 0), your_table_name::regclass) WHERE t_xmax ! 0; -- 筛选已删除行2.解析十六进制数据查询结果中的t_attrs字段通常以\x开头这是十六进制编码的文本。文本字段例如\x48656c6c6f对应Hello。整数字段通常占用 4 字节需注意大小端序PostgreSQL 使用小端序。例如01 00 00 00对应整数1。为了简化手动解析的痛苦建议创建一个辅助函数来批量转换CREATE OR REPLACE FUNCTION hex_to_text(hex_str text) RETURNS text AS $$ BEGIN -- 去除 \x 前缀并转换 RETURN convert_from(decode(substring(hex_str FROM 3), hex), UTF8); EXCEPTION WHEN OTHERS THEN RETURN hex_str; -- 转换失败返回原值 END; $$ LANGUAGE plpgsql;五、恢复方案 C基于 WAL 日志的时间点恢复如果数据已经被 VACUUM 清理或者上述方法无效且数据库开启了归档模式可以使用时间点恢复。确认配置确保postgresql.conf中开启了归档archive_mode on archive_command cp %p /path/to/archive/%f2.执行恢复停止数据库服务。使用pg_basebackup恢复基础备份。配置recovery.signal和postgresql.auto.conf指定恢复目标时间restore_command cp /path/to/archive/%f %p recovery_target_time 2026-04-08 09:00:00 -- 误删前的时间点启动数据库PG 将重放日志直到指定时间点。六、善后工作恢复配置数据恢复完成后务必记得重新开启自动清理否则表膨胀会导致性能严重下降。-- 重新开启自动清理 ALTER TABLE your_table_name RESET (autovacuum_enabled);七、总结与建议方案适用场景难度风险pg_dirtyread未执行 VACUUM可安装插件低低底层解析未执行 VACUUM无法安装插件高中需人工解析WAL 日志已执行 VACUUM有归档配置极高高需停机恢复备份还原有定期pg_dump备份中中数据可能回退