这些是实验结束后保留的两个应用层面的部分。

参数顺序稳定的预处理语句使得执行计划稳定且解析快速。它们也明确了需要索引什么。前面的代码块展示了 fetch_slice 和 fetch_trending；那就是实际部署的代码。

刷新 mv_trending 的作业每隔几分钟运行一次，使用 CONCURRENTLY 以保持读取端的顺畅。没有复杂的 cron 技巧，没有失效风暴。

如果你的缓存只是为了掩盖源站慢读，请先尝试修好源站。

把查询盖全，只预计算真正昂贵的部分。

度量 p95，别看平均。

如果直接走数据库能打败缓存未命中的长尾，还能减少运维痛苦，就让更简单的架构赢。

来源丨网址：https://medium.com/@the_atomic_architect/postgresql-18-killed-my-cache-layer-and-i-am-not-bringing-it-back-764496b2a9a5

*本文为dbaplus社群编译整理，如需转载请取得授权并标明出处！dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn