不能。postgresql触发器无法自动清理过期缓存数据，因其仅响应dml操作、无时间驱动能力，易致并发错删、性能阻塞及事务异常；应使用pg_cron、外部调度器或应用层定时任务解耦清理逻辑。
不能。 PostgreSQL 的触发器无法自动清理过期缓存数据，因为它不响应时间流逝，只响应 INSERT/UPDATE/DELETE 等显式 DML 操作；哪怕你写个 AFTER INSERT 触发器去删旧数据，也属于“被动响应写入”，不是“按时清理”，且极易引发并发错删、性能阻塞或事务异常。
为什么触发器不适合做定时清理
触发器本质是同步、事务内执行的逻辑，它的触发条件和执行时机完全由外部 SQL 语句驱动：
- 没有时间维度：
CURRENT_TIMESTAMP在触发器里每次求值都返回当前时刻，但不会“自己动起来”检查是否过期 - 无法解决“没人写入时数据仍过期”的问题：比如日志表连续 24 小时无新插入，过期数据就卡在那里不动
- 并发风险高：多个 INSERT 同时触发，可能各自查出同一组旧记录并重复 DELETE，或漏删（尤其没加
ORDER BY ... LIMIT 1时） - 拖慢主路径：原本毫秒级的 INSERT 可能因触发器里扫
created_at索引+删行变成几百毫秒，影响 API 延迟
PostgreSQL 中真正可用的定时清理方案
必须把“数据写入”和“数据清理”解耦。以下三种方式在生产环境验证有效，按推荐顺序排列：
-
pg_cron 扩展（首选）：在数据库内直接调度，无需依赖 OS 层。先在
postgres数据库执行CREATE EXTENSION pg_cron，再用SELECT cron.schedule('0 2 * * *', $$DELETE FROM cache WHERE expires_at 。注意函数名、SQL 字符串需严格单引号包裹，且清理语句必须带索引字段 <code>expires_at上的索引 -
cron + psql（最轻量）：写 shell 脚本调用
psql -U user -d db -c "DELETE FROM cache WHERE expires_at ，丢进系统 <code>crontab。适合 Docker 部署场景，避免额外扩展依赖 -
分区表 + 定期 DROP（仅限严格按时间分片）：若缓存表已按小时/天分区（如
cache_20260827），清理逻辑应查pg_partitioned_table和pg_get_expr(relpartbound, oid)解析真实边界，而非简单匹配表名，再执行DROP TABLE IF EXISTS
容易被忽略的关键细节
建完调度后，90% 的故障不是逻辑错，而是根本没跑起来：
- pg_cron 要确认后台进程在运行：
SELECT * FROM cron.job查状态，SELECT * FROM cron.job_run_details ORDER BY jobrunid DESC LIMIT 5看最近执行日志 - cron 脚本要用绝对路径调用
psql，且环境变量（如PGPASSWORD）需在 crontab 中显式设置，不能依赖用户 shell profile - 所有
DELETE必须带LIMIT（pg_cron 可配合循环函数，cron 脚本可加psql -c "WITH deleted AS (DELETE FROM ... RETURNING *) SELECT COUNT(*) FROM deleted"控制单次规模） -
expires_at字段必须有 B-tree 索引，否则WHERE expires_at 会全表扫描，大表下锁死写入
触发器只适合字段级轻量整形，比如 BEFORE INSERT 里修正 NEW.expires_at := COALESCE(NEW.expires_at, NOW() + INTERVAL '1 hour')；真要清过期数据，它连“守门员”都不是，只是个“顺手帮忙的临时工”，别让它扛主力。
