删 Redis 之后，系统反而更快了？Postgres 18 给了我底气

　　我把一整套 Redis 集群关掉了。

　　没人发现。

　　没有告警。

　　Slack 没人吵架。

　　延迟曲线：无波动。

　　我按下回车，看着监控图轻轻晃了一下，然后——

　　下降了。

　　那一刻我悟了： Postgres 18，干得比我维护多年的整个缓存层还稳。

　　下面，是这件事的来龙去脉、Postgres 18 到底带来了什么改变、以及你什么时候也可以放心删掉缓存 tier 而不会把 p95 弄炸。

　　多年间，我们的架构长这样（互联网“严肃架构图”的标准模板）：

　　 Clients|v+---------+ +--------+| API +------->| Redis |+---------+ +--------+| |v v+---------------+| PostgreSQL |+---------------+

　　读流程：

　　1. 查 Redis

　　2. 缓存 miss → 查 Postgres

　　3. 回写 Redis

　　我们觉得这才叫“专业”。

　　TTL 也调了。Eviction policy 也玩转了。

　　甚至还做过“缓存策略”的分享。

　　但某次大促晚上，Redis 爆炸了。

　　 CPU 90%

　　 网络顶满

　　 延迟乱蹦，但数据库完全没事，像在喝咖啡

　　 我们扩 Redis、调内存、调驱逐策略

　　 Postgres 全程无感：无聊得很

　　那次我第一次怀疑：“是不是哪里不对劲。”

　　我们花钱、花精力搭了个缓存层，结果它成了瓶颈。

　　在 18 版之前，我脑子里有条不成文规则：

　　“数据库必须保护，必须用缓存挡着。”

　　但 Postgres 18，让我第一次觉得：

　　也许数据库本身就能抗住。

　　它带来了 3 个对我们至关重要的升级：

　　Postgres 能自动 批量、合并多个读取请求 ，顺序扫描和位图堆扫描速度最高提升 3 倍 。

　　 2. 更聪明的索引使用（包括多列跳跃扫描 Skip Scan）

　　以前一些多列索引明明建了，优化器总是不听话。 现在终于“按你意愿”走了对的索引路径。

　　 3. 虚拟生成列（Virtual Generated Columns）

　　可以把一些“派生字段”直接放数据库里，读请求更快、更简单，不再需要 cache fill。

　　这三点结合，让我们冒出一个危险又诱人的想法：

　　“如果数据库本身就够快，那还要 Redis 干嘛？”

　　我没有直接删 Redis。 我做的是“暗流量测试”（dark launch）。

　　我们挑了一个最恼人的缓存相关查询：

　　 接口 ：用户仪表盘 dashboard

　　 行为模式 ：用户每天会点好几次

　　 旧逻辑 ：查用户资料 → 查订单 → 查状态 → 聚合 → 丢 Redis

　　我们先在 Postgres 18 上优化了查询。

　　 CREATEINDEX CONCURRENTLY idx_orders_customer_status_date ONorders(customer_id, status, created_at DESC);-- 简化的 Dashboard 查询SELECTo.id,o.total_amount,o.status,o.created_atFROMorders oWHEREo.customer_id =$1 ANDo.status IN('PAID', 'SHIPPED')ORDER BYo.created_at DESCLIMIT 20;

　　在 Postgres 18 之前，优化器总是给出一种“不咸不淡”的执行计划。 18 之后，它终于懂了“你想干嘛”。

　　然后我们在 staging 上打开 async I/O，把一小部分流量直接绕过 Redis 打到 Postgres。