Unlogged表通过跳过WAL日志提升性能，适用于可容忍数据丢失的场景。其核心是牺牲持久性换取写入加速，适合临时缓存、批量导入暂存等非关键数据存储。创建时使用CREATE UNLOGGED TABLE语句，数据仅存于内存和文件中，崩溃后会被清空。不支持主从复制，且不可用于高可用架构的关键数据。性能提升达20%-50%，尤其在高频写入场景优势明显。安全使用需命名标识、定期转存重要数据、应用层容错处理，并避免存储不可再生信息。

PostgreSQL中的unlogged表（非日志表）在特定场景下能显著提升性能，但其使用需要权衡数据安全性和持久性。这类表不写入WAL（Write-Ahead Logging），因此在崩溃或异常关闭时可能丢失数据。是否“安全”取决于你的业务需求和系统环境。

什么是Unlogged表？

默认情况下，PostgreSQL的所有表都是logged，即所有修改操作都会记录到WAL日志中，以确保崩溃恢复和复制的一致性。Unlogged表则跳过WAL写入，仅保留在共享内存和数据文件中。

创建方式如下：

CREATE UNLOGGED TABLE my_fast_table (
    id serial primary key,
    data text
);

Unlogged表的适用场景

这类表适合对数据持久性要求不高，但追求高性能的用例：

• 临时缓存数据，如会话状态、中间计算结果
• 批量导入过程中的暂存表
• 可重新生成的数据，比如报表预处理表
• 测试或开发环境中的模拟数据表

只要数据丢失后可以接受或能从其他来源重建，就可以考虑使用unlogged表。

潜在风险与限制

虽然性能更好，但存在明显缺点：

• 崩溃后数据丢失：实例崩溃或非干净关闭时，unlogged表内容会被清空
• 不支持逻辑复制或物理复制：主从复制不会同步这些表的数据
• 不适用于高可用架构中的关键数据存储
• VACUUM FULL、TRUNCATE等操作仍会留下少量日志痕迹，但整体不保证持久性

性能优势说明

由于省去了WAL写入的开销，unlogged表在以下操作中表现更优：

• 大量INSERT、UPDATE、DELETE操作
• 频繁的批量加载任务
• 高并发写入场景

实际测试中，写入速度可提升20%-50%，具体取决于硬件和负载类型。

如何安全使用Unlogged表

若决定使用，建议遵循以下实践：

• 明确标识unlogged表，命名上加上_temp或_unlogged后缀便于管理
• 定期将重要中间结果导出或转存到logged表
• 在应用层做好容错处理，假设这些表随时可能为空
• 避免在生产核心业务中存储不可再生的关键数据
• 监控数据库运行状态，尽量避免强制重启

基本上就这些。unlogged表不是不安全，而是用途特定。理解它的机制和边界，就能在性能和可靠性之间做出合理选择。