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表不是不安全，而是用途特定。理解它的机制和边界，就能在性能和可靠性之间做出合理选择。
