📌今日关键词：慢查询优化、物化视图、反规范化、覆盖索引、Redis缓存、JOIN优化、读性能、数据库优化
大家好，我是数据库小学妹 👋
上周在优化一个慢查询。一条SQL，跑了500多毫秒。执行计划一拉，四个表JOIN加GROUP BY聚合。当时第一反应是加索引，加完确实快了一点，但也就快了那么一点。心里就犯嘀咕，索引都加上了，怎么还是慢？
后来仔细看执行计划，才发现瓶颈不在索引。在JOIN本身。四张表一关联，数据量一上来，磁盘随机I/O直接把延迟拉爆了。
当时我就想，有没有办法把JOIN从读路径里拿掉？
研究了一段时间，找到了四种模式。每种都在测试环境跑过基准，今天把思路和踩过的坑整理出来，分享给同样在和慢查询较劲的朋友。
为什么JOIN会成为瓶颈？
JOIN在小数据量下没问题，很快。但数据涨到百万、千万级别，每次JOIN就是：
- 跨文件的随机I/O，磁盘寻址开销大
- 重复的堆查找，同一批数据被反复扫描
- 多次网络跳转，延迟一层层叠加
规范化是写入时的好设计。但读取路径上，JOIN的成本实实在在。要想降低读延迟，一个办法就是把JOIN从高频查询中拿掉。用更轻量的方式，拿到同样的数据。
四种模式总览
| 模式 | 适用场景 | 优化前 | 优化后 | 提升 |
|---|---|---|---|---|
| 物化视图 | 聚合报表、排行榜 | 520ms | 45ms | 11.6倍 |
| 反规范化JSONB | 读取产品+分类等关联信息 | 420ms | 28ms | 15.0倍 |
| 覆盖索引 | 高基数过滤+少量返回列 | 120ms | 10ms | 12.0倍 |
| 应用缓存(Redis) | 每次请求都需要的小参考数据 | 330ms | 18ms | 18.3倍 |
模式一：物化视图——把聚合结果提前算好
什么场景适合？
一个查询要关联四张表，再做SUM聚合。算过去30天的用户消费总额。每次请求都走一遍这个流程，p99飙到2秒以上。这种查询，加索引没用。瓶颈在聚合和JOIN，不在查找。
把聚合结果提前算好，存到一张物化视图里。读取时直接查这张小表。原始数据碰都不碰。
-- 创建物化聚合
CREATE MATERIALIZED VIEW mv_user_monthly AS
SELECT u.id AS user_id, sum(o.amount) AS total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created_at >= current_date - interval '30 days'
GROUP BY u.id;
-- 按需刷新
REFRESH MATERIALIZED VIEW mv_user_monthly;
读取就变成了：
SELECT user_id, total
FROM mv_user_monthly
WHERE total > 100;
结果：p50从520ms降到45ms，提升了11.6倍。p99从2200ms降到90ms，提升24.4倍。
有个坑差点没注意到
物化视图不是实时的。刷新周期内，你查到的是上一次的结果。业务能容忍几秒到几分钟的延迟，完全没问题。
但刷新方式要选对。我第一次用REFRESH MATERIALIZED VIEW没带CONCURRENTLY。刷新期间视图被锁，读取直接卡住。线上告警响了。生产环境一定要用REFRESH MATERIALIZED VIEW CONCURRENTLY。或者在业务低峰期刷新。
适合场景：仪表盘、排行榜、账单摘要。不适合写入后必须立即能读到的场景。
模式二：反规范化宽行——把引用数据塞进表里
什么场景适合？
每次读取产品信息，都要JOIN category和supplier两张小表。数据量不大，变更也不频繁。但每次读取都要关联一次，白白重复。
解决办法：把分类信息直接塞进产品表里，用JSONB字段存。查询时一张表搞定，不用再JOIN。
ALTER TABLE products ADD COLUMN cat jsonb;
UPDATE products p
SET cat = jsonb_build_object('id', c.id, 'name', c.name)
FROM categories c
WHERE p.category_id = c.id;
CREATE INDEX idx_products_cat_name ON products ((cat->>'name'));
读取：
SELECT id, cat->>'name' AS category
FROM products WHERE id = $1;
结果：p50从420ms降到28ms，提升15倍。写入端的代价是，分类信息变更时要同步更新反规范化的字段。或者接受最终一致性。
这个模式适合变更频率低的小参考表。分类、地区、供应商这种。高基数属性别往里塞。比如用户评论，JSONB字段会撑爆。业务上要求严格一致性的场景，也不适合用这个。
模式三：覆盖索引——索引直接返回结果
什么场景适合？
一个查询按status和created_at过滤，返回id和total。加了索引但还是慢？大概率是回表问题。索引定位到行之后，还要回到堆表里取数据。产生随机I/O。
把返回的列也塞进索引，数据库就不用回表了，直接从索引里拿数据。
CREATE INDEX idx_orders_cover
ON orders (status, created_at) INCLUDE (id, total);
查询：
SELECT id, total
FROM orders
WHERE status = 'paid' AND created_at >= '2025-01-01'
LIMIT 50;
结果：p50从120ms降到10ms，提升12倍。p99从680ms降到45ms，提升15倍。
这个模式风险低，投入产出比不错。但有个前提：返回的列不能太多。我见过有人把十几个字段全塞进索引。索引本身比表还大，写入性能也跟着遭殃。
模式四：应用端缓存——热点数据放Redis
什么场景适合？
每个请求都要查一次用户资料或组织设置。数据量小，查询频率高。但每次都要走数据库连接。说白了就是"为一个字段跑一趟数据库"，用缓存最合适。
热点参考数据放Redis。读取时先查缓存，miss了再查数据库，查到后回写缓存。
def get_user(uid):
key = f"user:{uid}"
data = r.hgetall(key)
if not data:
data = db.one(
"SELECT id,name,region FROM users WHERE id=%s", uid
)
r.hset(key, mapping=data)
return data
# 热路径直接用缓存
orders = db.all(
"SELECT id,total FROM orders WHERE user_id=%s", uid
)
结果：p50从330ms降到18ms，提升18倍。p99从1250ms降到120ms。
核心难点在缓存失效
缓存的难点不是怎么读。而是怎么保证数据不过期太久。常见的策略：
- 短TTL：设30秒到5分钟的过期时间，接受短暂不一致
- 写穿透：数据变更时主动更新或删除缓存key
- 发布/订阅：数据库变更事件广播给缓存服务。做精确失效。
怎么选？
其实就看你的查询特征。
聚合计算多、报表类的，用物化视图。读取时要好几个小参考字段的，用反规范化JSONB。查询条件固定、返回列少的高频读，覆盖索引最合适。每次请求都捞一个小数据，比如用户资料，直接上Redis。
实际项目里，这几种模式经常混着用。高频API用Redis缓存用户信息，订单查询走覆盖索引，报表走物化视图。没有哪种方案能包打天下。
避坑清单
- 上来就加索引或者上缓存之前，先跑EXPLAIN ANALYZE看执行计划。我之前就犯过这个错。索引加了一堆，结果瓶颈根本不在那里，白忙活。
- 反规范化的字段要有明确的同步机制。我在一个项目里见过，分类表改了名字。产品表里JSONB字段没人更新，前端显示的分类名和实际对不上。排查了半天才发现，问题出在反规范化没同步。写个触发器或者在业务层处理，别靠人记。
- 物化视图的刷新策略，上线前一定要想清楚。别问我怎么知道的，线上告警教过我一次了。
你在项目里有没有遇到过慢查询优化的场景？用了哪种方案，效果怎么样？欢迎评论区聊聊。说不定你的经验能帮到其他朋友。
我是数据库小学妹，咱们下篇见 👋
