在 PostgreSQL 中设置定时清理 30 天数据，最推荐的做法是使用操作系统 cron 任务配合 psql 命令，或者安装 pg_cron 扩展在数据库内部调度。核心 SQL 使用 CURRENT_TIMESTAMP - INTERVAL '30 days' 条件删除，但需注意大表删除可能引发 WAL 日志膨胀和锁表风险。
先说结论：PostgreSQL 原生不支持字段级自动 TTL，必须通过外部调度或扩展实现定时清理。
- 适合：拥有时间戳字段且数据量适中的业务表
- 先看：确认表是否有
created_at或类似时间列 - 建议：大表删除采用分批执行避免事务日志爆满
命令速用版
直接使用 SQL 语句清理超过 30 天的数据，配合 Linux crontab 实现自动化。
清理 SQL 示例：
DELETE FROM orders WHERE created_at < CURRENT_TIMESTAMP - INTERVAL '30 days';
定时任务配置（每天凌晨 2 点执行）：
0 2 * * * psql -U your_username -d your_database -c "DELETE FROM orders WHERE created_at < CURRENT_TIMESTAMP - INTERVAL '30 days';"
为什么会这样
PostgreSQL 设计上是关系型数据库，不像 Redis 或 MongoDB 原生支持字段级过期时间（TTL）。
数据库不会自动感知数据是否“过期”，必须依赖外部指令触发删除动作。常见的实现路径包括操作系统级定时任务、数据库内部扩展（如 pg_cron）或分区表管理。公开资料中没有看到可靠的量化数据表明哪种方式性能绝对最优，需根据运维架构选择。
分步处理
第一步：确保表结构包含时间列。创建表时添加 TIMESTAMP 列记录创建时间，例如 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP。
第二步：编写删除逻辑。使用 DELETE 语句配合时间间隔计算，确保条件覆盖目标数据范围。
第三步：配置调度器。若使用操作系统 cron，编辑 crontab 写入 psql 命令；若使用 pg_cron，需在数据库内创建 extension 并定义 job。
第四步：设置日志记录。建议在清理脚本中加入日志输出，记录删除行数和时间，便于后续审计。
怎么验证是否生效
执行清理任务后，查询表中最早的数据时间戳，确认是否大于 30 天前。使用命令 SELECT MIN(created_at) FROM orders; 检查。
查看数据库日志或 cron 邮件输出，确认任务执行状态为 success 且无报错。
若使用 pg_cron，可查询 pg_cron.job_run_details 视图查看历史执行记录。
常见坑
大表删除风险：默认事务下删除百万行数据会撑爆 WAL 日志，建议加 COMMIT 分批次删除，或使用 TRUNCATE 重置场景。
时区问题：确保数据库会话时区与业务一致，避免 CURRENT_TIMESTAMP 计算偏差。
锁表影响：避免在高峰时段运行清理任务，VACUUM 延迟可能影响查询性能。
权限不足：确保 cron 任务执行的数据库用户拥有目标表的 DELETE 权限。
常见问题
PostgreSQL 支持自动过期 TTL 吗？
不支持。MySQL 和 PostgreSQL 原生都不支持字段级 TTL，自动过期需通过定时任务实现。
大表删除数据太慢怎么办？
采用分批删除，每次删除固定行数并提交事务，避免长事务占用资源。
如何清理 pg_xlog 日志文件？
配置 postgresql.conf 中的相关参数启用自动清理，或通过脚本定期清理 pg_xlog 目录。
参考来源
1. PostgreSQL 定时清理旧数据的实现方法例子解析（2024 年 9 月 30 日）
2. 在 PostgreSQL 中实现数据的自动清理和过期清理例子解析（2024 年 9 月 27 日）
3. 在 PostgreSQL 里如何实现数据的自动清理和过期处理？（2024 年 7 月 8 日）