关于缓存，我的立场并非全盘否定。当你需要处理跨请求协调、速率限制，或是在不同服务间进行扇出扇入操作时，缓存或消息总线依然是可行的解决方案。我只是在那些因其掩盖优化器错误、增加查询波动性的场景中将其剔除。一个坦诚的分享：我曾尝试通过降低 synchronous_commit 参数来提升性能，但最终还是撤销了这项调整——对这条路径而言，写入语义层面的风险实在不值得冒险。
我在生产环境中停用了 Redis，并且从未回滚这一决定。”
每当想起这句话，我内心仍然会感到一阵紧张——毕竟缓存就如同系统的一条安全绳。但在 PostgreSQL 18 上经过大量谨慎测试后，p95 响应时间显著下降，系统架构更加简洁，值班团队的压力也随之减轻。
风险是真实存在的：用户会话、结算流程、我们的口碑信誉。
收益同样是真实的：更少的活跃组件、更少的告警短信。
下面我将分享自己的实践历程：我优化过的查询语句、关于唯一键的示意图，以及几个起到关键作用的小配置。
一、关闭缓存开关那一天
我们的热路径是一个参数化的产品查询，并附带一定的个性化特征。
缓存确实帮我们提高了命中率，但未命中的情况却相当棘手，而且序列化操作还额外增加了工作量。
我对这条路径进行了端到端的分析，随后尝试了一个更直接的数据库方案——使用更紧凑的索引和预先计算好的投影。
第一次运行结果令人心惊胆战……但随后数据逐渐稳定下来。
我让缓存停用了一个完整周期，见证了图表曲线最终趋于平静的过程。
二、Postgres里到底发生了什么
没有深奥的玄学，只有两件落地的事情：
1、覆盖度与选择性
覆盖索引配合生成列，让优化器能够只获取我们需要的字段，不再触及堆表。
2、预计算形态
物化视图（支持并发刷新）将原先依赖缓存隐藏的高昂聚合计算任务承接了过来。
PostgreSQL 18 凭借更智能的执行计划以及可预测的I/O完成了其余工作。
三、那个让Redis变得多余的查询
下面的表结构映射了一条常见的Feed流或目录切片场景：商品信息、软删除标识、新鲜度标记、个性化键值。
重点不在于字段名称，而是"生成列+覆盖索引"的组合完美匹配了返回结果。
应用程序调用随后变成了单次往返：
简而言之：规划器停留在索引层面，堆表保持"冷状态"，视图从热路径中移除了沉重的聚合操作。
四、从源头削减延迟
两个小的配置调整起到了重要作用。它们并非万能药，但确实让I/O保持稳定，并使优化器能够可靠地利用索引和并行性。
如果你在更快的本地NVMe上运行，设置较低的random_page_cost能保持索引扫描的吸引力。track_io_timing则会在你对自身磁盘性能判断有误时给出提示。
五、我是如何测量的
我运行了一个简单的客户端，它发出了我们通常会缓存的那组参数。下表来自我的测试环境，经过3次预热运行，显示的是中位数数据。网络跳数和序列化开销比人们预期的要多得多。
在我们的信息流端点测试中，直接的数据库路径击败了缓存未命中情况下的尾部延迟，同时消除了命中与未命中之间的悬崖式差距。那个差距过去常常出现在用户追踪记录和支持工单中。
六、前后对比，用ASCII图绘制
一个说服团队的过程流程图：
我们仍然保留了只读副本以确保安全，但热路径现在只有一个依赖项。
七、何时缓存仍然占优
我并不是反对缓存。如果你需要跨请求协调、速率窗口，或者是跨服务的扇出扇入操作，缓存或消息总线仍然有其用武之地。我只是在它掩盖了优化器错误并增加了方法差异的地方将它移除了。一个诚实的承认：我曾尝试通过降低synchronous_commit来榨取更多性能，但后来撤销了，因为对于这条路径来说，写入语义的风险不值得去冒。
八、我保留的可直接复用的更改
这些是实验结束后保留的两个应用层面的部分。
1、应用查询形态（SQL预处理语句），而非ORM猜测
参数顺序稳定的预编译语句使得执行计划稳定且解析迅速。它们也明确了需要什么索引。前面的代码块展示了fetch_slice和fetch_trending；那就是实际部署的代码。
2、适度、常规的刷新节奏
刷新mv_trending的作业每隔几分钟运行一次，使用CONCURRENTLY以保持读取端的流畅。没有复杂的cron技巧，没有失效风暴。
九、这对你的团队意味着什么
如果你的缓存只是为了掩盖源站慢读，请先尝试修复源站。
将查询完整覆盖，只预计算真正昂贵的部分。
关注p95分位点，别看平均值。
如果直接走数据库能击败缓存未命中的长尾，并减少运维痛苦，就让更简单的架构胜出。
作者│The Atomic Architect 编译│Rio
来源│网址：https://medium.com/@the_atomic_architect/postgresql-18-killed-my-cache-layer-and-i-am-not-bringing-it-back-764496b2a9a5
