性能优化 on 吾爱主机

PostgreSQL Autovacuum：触发机制、表膨胀与参数调优

Sat, 01 Aug 2026 00:00:00 +0800

PostgreSQL 使用 MVCC 让读写尽量互不阻塞，但它也带来一个容易被忽略的代价：UPDATE 和 DELETE 不会立刻从物理文件中移除旧版本。旧元组只有在不再可能被任何事务看到后，才能由 VACUUM 清理并把空间标记为可复用。

Autovacuum 不是“可有可无的后台整理器”，而是 PostgreSQL 稳定运行的基础设施。它同时承担回收死元组、更新优化器统计信息、维护可见性映射以及防止事务 ID 回卷等工作。本文从触发公式、监控 SQL和调优方法三个角度，解释如何避免表膨胀与查询性能逐步恶化。

一、为什么会产生死元组

假设执行：

UPDATE orders SET status = 'paid' WHERE id = 1001;

PostgreSQL 通常不会在原位置覆盖旧行，而是创建新版本，并让旧版本在满足可见性条件前继续存在。这样，较早开始的事务仍可读取它应该看到的快照。

当旧版本不再对任何事务可见时，它就成为 dead tuple。若清理速度长期低于写入速度，会出现：

表和索引占用空间持续增加；
顺序扫描需要读取更多数据页；
缓存命中效率下降，磁盘 I/O 增加；
优化器统计信息过旧，可能选择错误执行计划；
维护操作耗时越来越长。

需要注意：普通 VACUUM 主要把空间交还给表内部复用，通常不会立即缩小操作系统看到的文件。VACUUM FULL 会重写整张表并归还空间，但需要额外磁盘空间和排他锁，因此不适合作为日常维护手段。

二、Autovacuum 的触发公式

对更新和删除产生的死元组，触发阈值可近似理解为：

vacuum 触发数 = autovacuum_vacuum_threshold
 + autovacuum_vacuum_scale_factor × 表估算行数

PostgreSQL 18 的默认值为：

autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.2

一张估算为 1000 万行的表，默认需要约 200 万个更新或删除元组才触发一次 vacuum：

50 + 0.2 × 10,000,000 = 2,000,050

这对小表通常没问题，但对高频更新的大表可能过于宽松。分析统计信息的触发方式类似：

analyze 触发数 = autovacuum_analyze_threshold
 + autovacuum_analyze_scale_factor × 表估算行数

默认 autovacuum_analyze_threshold 为 50，autovacuum_analyze_scale_factor 为 0.1。

三、先监控，再调参数

1. 找出死元组较多的表

SELECT
 schemaname,
 relname,
 n_live_tup,
 n_dead_tup,
 round(
 100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0),
 2
 ) AS dead_pct,
 last_autovacuum,
 last_autoanalyze,
 autovacuum_count,
 autoanalyze_count
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

不要只盯着 dead_pct：百万行大表的 5% 可能已经很多，而几十行小表的 50% 通常影响有限。应同时观察绝对数量、增长速度、表尺寸和业务延迟。

2. 查看表与索引大小

SELECT
 n.nspname AS schema_name,
 c.relname AS table_name,
 pg_size_pretty(pg_table_size(c.oid)) AS table_size,
 pg_size_pretty(pg_indexes_size(c.oid)) AS indexes_size,
 pg_size_pretty(pg_total_relation_size(c.oid)) AS total_size
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
 AND n.nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_total_relation_size(c.oid) DESC
LIMIT 20;

pg_stat_user_tables 中的元组数是统计估算，不是严格实时计数。累计统计可能有短暂延迟，而且默认在同一事务中读取时会缓存到事务结束，因此排障时应避免在长事务里反复查询后误判数据没有变化。

3. 检查 Autovacuum 是否正在工作

SELECT
 pid,
 datname,
 relid::regclass AS table_name,
 phase,
 heap_blks_total,
 heap_blks_scanned,
 heap_blks_vacuumed,
 index_vacuum_count
FROM pg_stat_progress_vacuum;

同时检查全局配置：

SHOW autovacuum;
SHOW track_counts;
SHOW autovacuum_max_workers;
SHOW autovacuum_naptime;
SHOW autovacuum_vacuum_cost_delay;
SHOW autovacuum_vacuum_cost_limit;

四、针对热点大表做局部调优

相比一开始就修改全局配置，更稳妥的方式是为写入最频繁的表设置存储参数：

ALTER TABLE orders SET (
 autovacuum_vacuum_scale_factor = 0.02,
 autovacuum_vacuum_threshold = 1000,
 autovacuum_analyze_scale_factor = 0.02,
 autovacuum_analyze_threshold = 1000
);

若 orders 有 1000 万行，新的 vacuum 触发值约为：

1000 + 0.02 × 10,000,000 = 201,000

这比默认约 200 万行更及时，同时不会让所有表都采用同样激进的策略。调整后至少持续观察一个完整业务周期：

n_dead_tup 是否形成可控波动而非持续上升；
autovacuum 的执行次数与单次持续时间；
数据盘 IOPS、吞吐和延迟；
SQL 的 P95/P99 延迟；
表和索引尺寸是否趋于稳定。

五、为什么“调低阈值”仍可能无效

1. 长事务阻止清理

只要某个老快照仍可能看见旧版本，VACUUM 就不能安全移除它。可先排查长时间未结束的事务：

SELECT
 pid,
 usename,
 state,
 xact_start,
 now() - xact_start AS xact_age,
 wait_event_type,
 wait_event,
 left(query, 120) AS query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;

应用连接池中的 idle in transaction、未提交的批处理、长期保持的报表事务，都是常见根因。此时继续降低 scale factor，只会让 vacuum 更频繁地尝试，却未必能回收空间。

2. 清理能力跟不上写入速度

Autovacuum 使用基于成本的延迟机制来降低后台维护对前台业务的 I/O 冲击。如果多张大表同时高频更新，worker 数量、成本限额或磁盘能力可能成为瓶颈。

调优顺序建议是：

先解决长事务和异常写入；
针对热点表降低触发阈值；
确认磁盘有余量后，再评估 worker 数量和成本参数；
每次只改一组参数，并保留前后监控数据。

不要只为“让 vacuum 尽快结束”就无限提高成本限额，否则维护 I/O 可能直接影响在线查询。

3. 误把内部可复用空间当成故障

普通 VACUUM 后文件不缩小，并不表示它没有工作。若表仍会持续写入，保留并复用这些空闲空间往往比频繁执行 VACUUM FULL 更合理。

只有在一次性大规模删除、确认未来不会很快重新增长，并且能够安排锁表维护窗口时，才考虑 VACUUM FULL、CLUSTER 或其他表重写方案。执行前必须预留接近表及索引重建所需的额外空间。

六、生产调优清单

保持 autovacuum 开启，不要把关闭它当成性能优化。
用 pg_stat_user_tables 建立死元组数量、比例和清理时间的趋势图。
优先为热点大表设置表级参数，避免粗暴修改全局阈值。
同时监控磁盘 I/O 和业务延迟，防止维护任务挤压前台负载。
排查长事务、复制槽和其他可能维持旧快照的因素。
将普通 VACUUM 作为日常机制，把表重写当作有维护窗口的例外操作。
定期检查事务 ID 年龄，不能只关注磁盘膨胀。

总结

Autovacuum 的本质不是“定时清垃圾”，而是根据表的变更规模动态触发的一组维护任务。真正有效的优化，不是简单把参数调得更激进，而是让触发频率、清理吞吐和业务写入速度达到平衡。

面对表膨胀时，应先回答三个问题：死元组为什么持续产生、为什么未被及时清理、普通 VACUUM 回收的空间是否已经被业务复用。把这些问题与长事务、I/O 能力和表级阈值结合起来分析，通常比直接执行 VACUUM FULL 更安全，也更接近根因。

参考资料

PostgreSQL B-tree 索引：结构、扫描方式与工程实践

Fri, 24 Jul 2026 00:00:00 +0800

线上 SQL 变慢时，第一反应往往是“加个索引”。但在 PostgreSQL 里，索引不是“有就快”的开关：默认的 B-tree 适合哪些谓词？多列索引为什么“左边优先”？为什么 EXPLAIN 里会出现 Index Scan、Bitmap Heap Scan 或 Index Only Scan？部分索引、INCLUDE 覆盖列、CREATE INDEX CONCURRENTLY 又分别解决什么工程问题？

本文基于 PostgreSQL 官方文档（当前文档站对应 PostgreSQL 18 手册章节），从机制讲到可复现实验与排错清单，帮助你把索引用在真正该用的地方。

问题背景：没有索引时，数据库在做什么

官方索引导论用了一个很直观的例子：表 test1(id, content) 上频繁执行：

SELECT content FROM test1 WHERE id = constant;

如果没有预先准备，系统只能 逐行扫描整表 找匹配行；行数很大而命中很少时，这显然低效。若在 id 上维护索引，定位匹配行可以走更高效的路径（例如在搜索树中只走几层），而不必通读整本书式的堆表。

关键工程含义：

索引要提前“预见”查询会怎样查找数据——这是 DBA/开发者的职责，而不是数据库自动替你猜对所有场景。
索引创建后会随表的增删改自动维护，但也会带来 写放大与存储开销。
规划器是否选用索引，依赖统计信息；因此要定期 ANALYZE，并学会用 EXPLAIN 验证真实计划。

核心原理：为什么日常几乎都是 B-tree

PostgreSQL 提供多种索引访问方法：B-tree、Hash、GiST、SP-GiST、GIN、BRIN，以及扩展如 bloom。
CREATE INDEX 默认创建 B-tree，因为它覆盖了最常见的相等与范围查询场景。其它类型需要显式 USING method，例如：

CREATE INDEX name ON table USING HASH (column);

B-tree 能加速哪些谓词

官方说明：B-tree 可处理 可排序数据 上的相等与范围查询。规划器会在索引列参与下列比较时考虑使用 B-tree：

运算符 / 形态	说明
`<` `<=` `=` `>=` `>`	基本比较
`BETWEEN` / `IN`	可视为上述比较的组合
`IS NULL` / `IS NOT NULL`	也可用于 B-tree
`LIKE` / `~`	仅当模式为常量且锚定在字符串开头，如 `col LIKE 'foo%'`、`col ~ '^foo'`；`'%bar'` 这类前后缀/中间匹配不行

补充：

非 C locale 时，模式匹配类查询可能需要特殊 operator class 才能用索引（见手册“Operator Classes and Operator Families”相关章节）。
ILIKE / ~* 更受限：模式通常需要以“不受大小写转换影响的字符”开头。
Hash 索引 只存 32-bit 哈希码，因此 只能处理简单相等比较，不能替代 B-tree 的范围与排序能力。

只有 B-tree 能“带着顺序”吐行

索引除了找行，还可能直接按指定顺序交付结果，从而避免额外排序。官方明确：在当前支持的索引类型中，只有 B-tree 能产生有序输出；其它类型返回匹配行的顺序是未指定、实现相关的。

默认 B-tree 条目按 升序、NULLS LAST 存储（相等时用表 TID 作决胜列）。因此：

正向扫描满足 ORDER BY x（即 ASC NULLS LAST）
反向扫描可满足 ORDER BY x DESC（对应 DESC NULLS FIRST 等组合规则）

工程上特别有价值的形态是 ORDER BY ... LIMIT n：显式排序往往要处理全部候选才能取前 n 行；若有匹配的 B-tree，可直接取前 n 行，无需扫完剩余数据。

唯一性约束如何落地

目前只有 B-tree 可声明为 unique。
默认情况下，唯一列中的 多个 NULL 不视为相等（允许多个 NULL）；NULLS NOT DISTINCT 会把 NULL 当相等处理。
定义 PRIMARY KEY / UNIQUE 约束时，PostgreSQL 会自动创建 对应唯一索引，无需再手写一份重复索引。

扫描方式：同一条 SQL，三种常见“走路方式”

PostgreSQL 的索引是 二级索引（secondary index）：索引与堆表（heap）分开存储。普通索引扫描通常既读索引，又回表读堆；匹配的索引项可能相邻，但对应堆行可能散落各处，带来随机 I/O。

1）Index Scan：点查 / 高选择性范围

适合“索引快速锁定少量行，再回表取完整行”的路径。EXPLAIN 中常见 Index Scan using ...。

2）Bitmap Index Scan + Bitmap Heap Scan：中等选择性或组合条件

当需要组合多个索引、或单次索引扫描无法直接表达某些 OR/AND 形态时，系统可：

扫描一个或多个索引，在内存中生成 bitmap（标记可能命中的堆位置）
对 bitmap 做 AND / OR
再按 物理顺序 访问堆表（Bitmap Heap Scan）

官方指出：按物理序访问会 丢失原索引顺序，因此后续若需要排序，可能再加 Sort。这也解释了：bitmap 路径擅长降低随机 I/O，但不一定能顺便满足 ORDER BY。

3）Index Only Scan：尽量不回表

Index-only scan 的目标是 只靠索引回答查询。官方给出两个基本前提：

索引类型支持 index-only scan：B-tree 始终支持；GiST/SP-GiST 仅部分 operator class；GIN 等通常不支持（索引项往往只存原值的一部分）。
查询只引用索引中存有的列。例如索引在 (x, y) 上：
- 可用：SELECT x, y FROM tab WHERE x = 'key';
- 不可用（还要读 z）：SELECT x, z FROM tab WHERE x = 'key';

即便列都在索引里，PostgreSQL 仍要做 MVCC 可见性 判断。可见性信息不在索引项里，而在堆中；因此引入 visibility map（可见性映射）：

若堆页对应 all-visible 位已设置，可认为行对当前/未来事务可见，无需再访问堆元组
若未设置，仍需回表检查可见性——此时相对普通 Index Scan 的收益会明显下降

因此：Index Only Scan “物理上可能”，但 只有当表中相当比例堆页的 all-visible 位有效时 才更划算。对“大量行很少变化”的表，这类扫描非常实用；写很频繁、可见性图难以保持的表，收益会打折。

覆盖索引与 `INCLUDE`

为了让高频查询更容易走 index-only，可以做 covering index（覆盖索引）：让索引包含查询需要返回/过滤的列。PostgreSQL 允许用 INCLUDE 添加 非键（non-key）列：

非键列不能用于索引扫描的查找条件，也不参与唯一/排他约束判定
但 index-only scan 可直接从索引叶子返回这些列，无需回表
INCLUDE 列会增大索引、复制数据；宽列要谨慎
带 non-key 列的 B-tree 不会使用 deduplication
表达式不能作为 INCLUDE 列（因为无法用于 index-only scan）
当前 B-tree / GiST / SP-GiST 支持该特性；叶子存 INCLUDE 值，上层导航项不包含它们

-- 键列用于查找，INCLUDE 列服务于覆盖返回
CREATE INDEX orders_user_created_cover
 ON orders (user_id, created_at)
 INCLUDE (status, amount);

多列索引、部分索引：选型比“多建几个”更重要

多列 B-tree：最左前缀与效率

索引最多 32 列（含 INCLUDE；编译期可改 pg_config_manual.h）。
多键列目前由 B-tree、GiST、GIN、BRIN 等支持（与能否 INCLUDE 是两件独立的事）。
多列 B-tree 可用于涉及任意列子集的条件，但 在前导（最左）列上有约束时最高效。
精确规则（官方表述）：对前导列的 相等约束，加上第一个没有相等约束的列上的 不等式约束，总是用于限制扫描的索引区间；更右侧列上的条件仍会在索引内检查（可减少回表），但不一定缩小扫描区间。
新版本还有 skip scan 优化：在合适基数下，可对缺少常规相等约束的中间列做内部动态相等约束，减少读取区间——但这是优化，不是让你随意打乱“左前缀”设计习惯。

经验对照：

查询形态	更合适的索引直觉
总是 `WHERE a = ? AND b = ?`	`(a, b)` 复合索引
有时只有 `a`，有时只有 `b`，有时两者	可能两个单列 + 让规划器组合；或评估 skip scan / 复合
`ORDER BY a, b LIMIT n`	与排序方向一致的 `(a, b)` B-tree
只查“活跃订单”等小子集	部分索引往往比全表索引更划算

部分索引：只索引“值得索引”的子集

部分索引建立在表的一个子集上，子集由谓词（WHERE）定义，索引 只包含满足谓词的行。

官方给出的核心动机：

避免给常见值建索引：若某值占比很高，查它本来也未必走索引，放进索引只会白白增大体积、拖慢写路径。
缩小索引 → 命中索引的查询更快，且很多更新不必维护该索引。

典型场景：访问日志中组织内网 IP 占比极高，但排查更关心外部 IP：

CREATE INDEX access_log_client_ip_ix
 ON access_log (client_ip)
 WHERE NOT (
 client_ip > inet '192.168.100.0'
 AND client_ip < inet '192.168.100.255'
 );

只有查询条件也落在“被索引子集”内时，规划器才能使用该部分索引；条件与谓词冲突时不会用。

可复现实验：从建表到读懂 EXPLAIN

下面用一套小实验把机制落到命令（在任意 PostgreSQL ≥ 14 环境可跑；语句本身与官方语义一致）。

-- 1) 准备数据
DROP TABLE IF EXISTS demo_orders;
CREATE TABLE demo_orders (
 id bigserial PRIMARY KEY,
 user_id int NOT NULL,
 status text NOT NULL,
 amount numeric(12,2) NOT NULL,
 created_at timestamptz NOT NULL DEFAULT now()
);

INSERT INTO demo_orders (user_id, status, amount, created_at)
SELECT
 (random()*10000)::int,
 (ARRAY['paid','pending','cancelled','paid','paid'])[1 + (random()*4)::int],
 round((random()*500)::numeric, 2),
 now() - ((random()*365)::int || ' days')::interval
FROM generate_series(1, 200000);

ANALYZE demo_orders;

-- 2) 无业务二级索引时看计划（主键本身是 B-tree 唯一索引）
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM demo_orders WHERE user_id = 42;

-- 3) 建立常用复合索引 + 部分索引 + 覆盖索引
CREATE INDEX CONCURRENTLY demo_orders_user_created_idx
 ON demo_orders (user_id, created_at DESC);

CREATE INDEX CONCURRENTLY demo_orders_pending_idx
 ON demo_orders (created_at)
 WHERE status = 'pending';

CREATE INDEX CONCURRENTLY demo_orders_user_cover_idx
 ON demo_orders (user_id)
 INCLUDE (status, amount);

ANALYZE demo_orders;

-- 4) 对比计划节点名称
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, status, amount
FROM demo_orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 20;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at
FROM demo_orders
WHERE status = 'pending'
 AND created_at > now() - interval '7 days';

EXPLAIN (ANALYZE, BUFFERS)
SELECT user_id, status, amount
FROM demo_orders
WHERE user_id = 42;
-- 若统计与可见性合适，可能出现 Index Only Scan（依赖 INCLUDE 覆盖 + visibility map）

读计划时优先看：

节点类型：Seq Scan / Index Scan / Bitmap Index Scan + Bitmap Heap Scan / Index Only Scan
实际行数 vs 估算行数（rows）：偏差大 → 统计过期或谓词难估，先 ANALYZE，再考虑扩展统计
Buffers：命中共享缓冲还是读盘；Index Only Scan 是否仍有大量 heap fetches（可见性图不给力）
是否多了不必要的 Sort：排序方向与索引 (ASC/DESC, NULLS ...) 是否一致

生产变更：`CREATE INDEX CONCURRENTLY`

普通 CREATE INDEX 会对表加写锁：其它事务仍可读，但 INSERT/UPDATE/DELETE 会阻塞到索引建完。大表上这可能长达数小时，生产不可接受。

CREATE INDEX CONCURRENTLY 的官方要点：

构建过程 不获取会阻止并发写 的锁（允许正常 DML 继续）
代价：通常要 两次表扫描，并等待可能修改/使用该索引的相关事务结束，总工作量更大、耗时更长
过程中索引会先以 INVALID 状态进入系统目录；成功结束后才标为可用
若扫描阶段失败（死锁、唯一冲突等），命令失败但可能留下 INVALID 索引：查询会忽略它，却仍要为写维护它 → 推荐 DROP 后重试 CREATE INDEX CONCURRENTLY（或 REINDEX INDEX CONCURRENTLY）
CREATE INDEX CONCURRENTLY 不能放在事务块里；分区表并发构建有额外限制（可先对分区并发建，再非并发建分区父索引以缩短写锁定窗口）
同一表上 同时只能有一个 concurrent index build

CREATE INDEX CONCURRENTLY sales_quantity_index
 ON sales_table (quantity);

常见坑与排查清单

现象	常见原因	怎么查 / 怎么办
建了索引仍 `Seq Scan`	选择性差、统计过期、函数包住列导致无法匹配、成本模型认为全表更便宜	`EXPLAIN`；`ANALYZE`；避免 `WHERE func(col)=...`（改表达式索引）；用真实参数看计划
`LIKE '%x%'` 不走 B-tree	B-tree 需要前缀锚定模式	换 `pg_trgm` + GIN/GiST 等（另一条路线，不是默认 B-tree）
多列索引“像没用”	谓词没落在最左列，或类型/排序规则不匹配	检查前导列是否有相等/范围条件；核对 `ASC/DESC NULLS`
期望 Index Only Scan 却回表很多	查询列未覆盖；visibility map 中 all-visible 比例低	`INCLUDE` 覆盖；减少无意义更新；关注 vacuum 是否跟上
写变慢、膨胀	索引过多、宽 INCLUDE、低选择性索引	用 `pg_stat_user_indexes` 看扫描次数；删冗余；部分索引收窄
`CONCURRENTLY` 后有 `INVALID`	构建失败留下残留	`\d table` 确认；`DROP INDEX` 后重建
唯一约束“允许多个 NULL”	默认 NULL 不相等	需要业务唯一含 NULL 时用 `NULLS NOT DISTINCT`

辅助观测：

-- 索引是否被使用（需打开 stats）
SELECT schemaname, relname, indexrelname, idx_scan, idx_tup_read, idx_tup_fetch
FROM pg_stat_user_indexes
ORDER BY idx_scan ASC
LIMIT 30;

-- 无效索引排查（概念：concurrent 失败残留）
SELECT c.relname AS index_name, i.indisvalid
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
WHERE NOT i.indisvalid;

工程实践建议（可直接落地）

先写清访问路径：等值 / 范围 / 排序 / 覆盖返回列 / 是否只查子集。
默认从 B-tree 开始：范围、排序、唯一约束几乎都靠它；Hash 仅在“只要相等且理解其限制”时考虑。
复合索引按过滤+排序设计列序：高频等值列靠左，范围/排序列靠右；方向与 ORDER BY 对齐。
热点子集优先部分索引：状态机里的 pending、软删除后的“有效行”、租户内活跃数据等。
高频只读投影再谈 INCLUDE：覆盖收益要压过索引变大与 dedup 失效的代价。
生产建索引用 CONCURRENTLY，并处理 INVALID 残留。
用 EXPLAIN (ANALYZE, BUFFERS) 闭环，而不是用“感觉”判断索引是否生效。

总结

PostgreSQL 索引体系的核心不是“类型清单”，而是三层决策：

访问方法：日常以 B-tree 承载相等、范围、排序与唯一性；Hash/GIN/GiST/BRIN 解决更专门的谓词与数据形态。
扫描算子：Index Scan 精确定位，Bitmap 组合与减少随机 I/O，Index Only Scan 在覆盖列 + 可见性图友好时避免回表。
工程形态：多列最左前缀、部分索引缩子集、INCLUDE 做覆盖、CONCURRENTLY 保障在线变更。

把这三层和 EXPLAIN 对上，索引才会从“玄学加速”变成可验证的性能工具。

参考资料

HTTP 条件请求与缓存协商：ETag、Last-Modified 与 Cache-Control 工程实践

Wed, 15 Jul 2026 00:00:00 +0800

很多系统的“慢”并不在业务逻辑，而在重复传输不变的响应体。浏览器、CDN、反向代理都可能持有一份旧副本；真正关键的是：这份副本还能不能直接用？如果不能直接用，能否只问服务器“变了没有”？

HTTP 把这件事拆成两层：

新鲜度（freshness）：缓存还在不在有效期内，决定要不要立刻回源；
验证（validation）：过期或必须再确认时，用条件请求做协商，成功则返回 304 Not Modified，避免再次传输实体。

本文基于 HTTP 语义规范（RFC 9110）与 HTTP 缓存规范（RFC 9111），结合 Nginx 能力，讲清楚 Cache-Control、ETag / Last-Modified、If-None-Match / If-Modified-Since 的协作关系，以及可落地的配置与排错方法。

一、先分清：存下来 ≠ 可以直接用

RFC 9111 把缓存决策大致分成：

阶段	问题	关键概念
存储（store）	响应能不能进缓存	方法、状态码、`no-store`、`private`、`Authorization` 等
新鲜度（fresh）	已存副本是否仍 fresh	`max-age` / `s-maxage` / `Expires` / Age
验证（validate）	stale 后能否复用	条件请求 + 校验器（validator）
复用（reuse）	最终回什么	200 全量、304 无 body、或回源新响应

常见误解：

no-cache 不是“禁止缓存”。它表示：可以用存储副本，但必须先成功验证后才能拿去满足其他请求。
no-store 才是“不要存”。缓存不得存储该请求/响应的任何部分，也不能拿它去满足别的请求。
private 不是“浏览器也不能缓存”。它限制的是共享缓存（CDN、公司代理）：响应面向单个用户；私有缓存（浏览器）仍可在规则允许下存储。

把语义说清楚，后面的工程配置才不会互相打架。

二、新鲜度：Cache-Control 的核心指令

1. 响应侧最常用指令

指令	含义（工程视角）
`max-age=N`	响应在 age > N 秒后视为 stale
`s-maxage=N`	只对共享缓存覆盖 `max-age`/`Expires`；并带有必须再验证后才能复用 stale 的语义
`public`	明确允许缓存（例如带 `Authorization` 的响应在共享缓存中的场景）
`private`	禁止共享缓存存储（或限定字段）
`no-cache`	使用前必须验证
`no-store`	不要存储
`must-revalidate`	一旦 stale，不得在未验证成功前复用；断连时更应报错而不是偷偷给 stale

一个可记的分层：

# 静态资源：可公开、长期缓存（内容指纹化后）
Cache-Control: public, max-age=31536000, immutable

# HTML 入口：可缓存但每次用前确认
Cache-Control: no-cache

# 登录态 API：不要被中间层存
Cache-Control: private, no-store

# 对一致性要求高的共享缓存内容
Cache-Control: public, max-age=60, must-revalidate

2. Age 与“看起来刚生成”

响应里的 Age 表示估计已在缓存中停留的秒数。共享缓存命中时，客户端看到的“年龄”往往不是 0。排查“为什么我设了 max-age=60，却总在提前回源”时，要同时看：

源站给出的 Cache-Control / Expires
中间层是否改写了头
响应是否已有较大 Age

3. 启发式新鲜度：别依赖“没写过期时间也碰巧能缓存”

没有显式过期信息时，部分缓存会用启发式算法估算 fresh 时间。这在不同实现间差异大，生产环境应显式给出 freshness，不要赌默认行为。

三、校验器：ETag 与 Last-Modified

验证阶段依赖表示元数据（representation metadata），最常见两类：

1. `Last-Modified`

源站认为所选表示最后修改的时间（HTTP-date）。例如：

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

优点：实现简单，文件系统/对象存储天然具备 mtime。
局限：

秒级精度，一秒内多次变更可能撞车；
时钟回拨、多副本 mtime 不一致会误判；
内容没变但元数据变了时，语义可能不够准。

2. `ETag`（实体标签）

ETag 是源站为某个表示分配的不透明标签：

ETag: "xyzzy"
ETag: W/"xyzzy"

强校验器（strong）：表示数据（以及会影响 200 内容的关键元数据）变化时标签应变化。适合字节级精确比较。
弱校验器（weak，W/ 前缀）：语义等价即可，即使字节不完全相同。生成成本更低，但比较能力更弱。

RFC 9110 明确：在不便存修改时间、一秒精度不够、或修改时间维护不一致时，ETag 通常比 Last-Modified 更可靠。

工程上常见生成策略：

策略	适用	注意
内容哈希（SHA-256 截断）	静态文件、构建产物	强 ETag，成本随体积上升
版本号 / 修订号	业务资源、CMS	发布流程必须保证“内容变则版本变”
inode + size + mtime	传统文件服务器	迁移/复制后可能变，跨机一致性差
弱 ETag（模板渲染摘要）	HTML 片段语义不变	不要拿去当字节级一致性保证

四、条件请求：如何问“变了没有”

1. `If-None-Match`（优先，基于 ETag）

客户端/缓存带上已存表示的 ETag：

GET /app.js HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

源站比较当前 ETag：

匹配（表示未变）→ 304 Not Modified，通常无 body；
不匹配 → 200 OK + 新表示（含新的 ETag）。

对 If-None-Match，规范要求使用弱比较函数：即使只有弱 ETag，也可用于缓存验证。

2. `If-Modified-Since`（基于时间）

GET /style.css HTTP/1.1
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

若所选表示的修改时间不比该日期更新，则不必再传实体。

3. 两者同时出现时谁说了算？

RFC 9110 规定：若请求里带了 If-None-Match，接收方必须忽略 If-Modified-Since——因为实体标签被认为是更准确的替代条件。两者同时出现多是兼容历史客户端；服务端实现应按规范优先级处理。

4. `304 Not Modified` 到底省了什么

304 表示：若没有条件约束，这次本应是 200；但条件为假（未修改），客户端应继续使用本地已存表示。

源站仍应带上在同等 200 中会发送的关键头（如 ETag、Date、Content-Location 等），以便缓存刷新元数据（freshen），而不只是“空响应”。

流量层面：

首次：200 + 完整 body（例如 800KB）
之后未变更：304 + 几乎无 body（通常几百字节头）

对静态资源、移动端弱网、跨境回源，收益非常明显。

五、一张图串起完整路径

Client/CDN 本地有副本？
 |
 | 无 -----> 普通 GET -----> 200 + body + Cache-Control + ETag/LM
 |
 | 有且 fresh -----> 直接复用（不回源）
 |
 | 有但 stale / 或 no-cache
 v
 条件请求：If-None-Match / If-Modified-Since
 |
 +--> 未变：304（刷新头，复用旧 body）
 |
 +--> 已变：200（新 body + 新校验器）

记住两句话：

fresh 解决“要不要问”；
validator 解决“问了以后要不要传 body”。

只有 max-age 没有校验器，过期后往往只能全量回源；只有 ETag 没有合理 freshness，会变成“每次都协商”，仍然浪费 RTT。

六、工程实践：按资源类型给策略

1. 带内容哈希的静态资源（最推荐）

构建后文件名含 hash，例如 app.3f2a1c.js：

location /static/ {
 # 文件名已指纹化，可大胆长缓存
 expires 365d;
 add_header Cache-Control "public, max-age=31536000, immutable";
}

要点：

URL 变 = 内容变，可用超长 max-age；
immutable 提示浏览器在 freshness 内不必做启发式再验证（支持情况因客户端而异，但不妨碍给出）；
旧 URL 自然失效，无需纠结主动 purge 每一个文件。

2. HTML / 入口文档

入口常引用带 hash 的静态资源，自身却要尽快看到新版本：

Cache-Control: no-cache
ETag: "html-rev-42"

或短 max-age + 强制再验证：

Cache-Control: max-age=0, must-revalidate
ETag: "html-rev-42"

这样浏览器/边缘仍可存副本，但使用前会走条件请求；HTML 未变则 304，变了才下新文档。

3. 个性化或含凭证的 API

Cache-Control: private, no-store

原因：

private 避免 CDN 把用户 A 的响应给用户 B；
no-store 进一步降低敏感信息落盘风险。

注意：no-store 不是完备隐私方案（恶意或失控缓存可能不遵守），敏感数据仍要靠鉴权、最小化返回字段和传输安全。

4. 可被 CDN 缓存的公共 API / 配置

Cache-Control: public, s-maxage=30, max-age=10
ETag: "cfg-20260715-1"

浏览器短缓存（max-age）；
CDN 稍长（s-maxage）；
过期后用 ETag 协商，降低源站带宽。

Nginx 反代缓存可配合：

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:50m inactive=10m;

location /api/public/ {
 proxy_cache api_cache;
 proxy_cache_valid 200 30s;
 # 过期后用条件请求回源校验
 proxy_cache_revalidate on;
 # 更新期间允许短暂提供 stale，降低源站抖动影响
 proxy_cache_use_stale updating error timeout http_500 http_502 http_503;
 proxy_pass http://upstream;
}

proxy_cache_revalidate on 的作用，正是在缓存过期后启用 If-Modified-Since / If-None-Match 条件回源——这与 RFC 里的 validation 模型一致。

七、服务端如何正确实现条件 GET

以伪代码说明最小正确逻辑：

def handle_get(request, resource):
 etag = resource.strong_etag() # 例如 '"%s"' % sha256(body)[:16]
 last_mod = resource.last_modified_http_date()

 # 1) 优先处理 If-None-Match
 inm = request.headers.get("If-None-Match")
 if inm:
 if etag_matches(inm, etag): # 按弱比较规则实现
 return response_304(etag=etag, last_modified=last_mod)
 return response_200(resource, etag=etag, last_modified=last_mod)

 # 2) 否则再看 If-Modified-Since
 ims = request.headers.get("If-Modified-Since")
 if ims and not resource.modified_after(ims):
 return response_304(etag=etag, last_modified=last_mod)

 return response_200(resource, etag=etag, last_modified=last_mod)

实现清单：

同一表示的 ETag 必须稳定：相同内容不要每次随机；
内容变更必须换 ETag：漏更新会造成“改了却一直 304”；
Vary 要配对：若响应随 Accept-Encoding / Authorization / 自定义头变化，必须正确 Vary，否则缓存会串内容；
压缩前后一致性：对 gzip/br 内容，ETag 策略要与表示选择一致，避免“协商错表示”；
不要手动拼错弱标记：W/ 大小写敏感，格式为 W/"tag"。

八、常见坑与排查清单

坑 1：`no-cache` 和 `no-store` 用反

想“每次确认后再用本地副本” → no-cache（或 max-age=0, must-revalidate）+ ETag；
想“别存敏感响应” → no-store（通常再加 private）。

坑 2：只配了长缓存，没有内容指纹

Cache-Control: max-age=31536000 配在固定 URL 的 app.js 上，发版后用户会长时间用旧脚本。正确做法是 hash 文件名 或主动缩短 freshness 并保证能 purge。

坑 3：ETag 在多实例间不一致

滚动发布时实例 A/B 对同一文件算出不同 ETag（例如混入了进程启动时间），客户端会在 200/304 间抖动，缓存命中率暴跌。校验器生成必须内容决定论。

坑 4：中间层剥掉了校验器或改写了 Cache-Control

排查命令：

# 看源站
curl -sI https://origin.example.com/static/app.js | sed -n '1,20p'

# 看经 CDN/Nginx 后
curl -sI https://www.example.com/static/app.js | sed -n '1,20p'

# 模拟条件请求
ETAG='"abc123"'
curl -sI -H "If-None-Match: $ETAG" https://www.example.com/static/app.js | sed -n '1,15p'

对比：ETag、Cache-Control、Age、CF-Cache-Status/X-Cache 等是否符合预期。第二次应看到 304（在 ETag 仍匹配时）。

坑 5：API 被共享缓存误缓存

带 cookie/authorization 的响应若缺少 private/no-store，再叠加错误的 public，可能把用户数据缓存到边缘。对用户相关响应默认保守，对真正公共的 GET 再显式放开。

坑 6：304 后客户端仍像“没更新样式”

常见是 HTML 长缓存，或 Service Worker / 应用内二次缓存。协议层 304 只保证这一跳 HTTP 缓存协商；还要检查：

HTML 的 Cache-Control；
SW 的 cache.addAll 策略；
应用本地 localStorage 里的资源清单。

九、选型小结

目标	推荐组合
最大化静态资源性能	内容哈希 URL + 长 `max-age` + `public`
入口文档尽快更新	`no-cache` 或短 max-age + ETag + 304
公共只读 API 降源站负载	`s-maxage` + ETag + CDN `proxy_cache_revalidate`
用户私有数据	`private, no-store`，默认不进共享缓存
过期后仍要强一致	`must-revalidate` / `proxy-revalidate` / `s-maxage` 语义

原则：

用 freshness 控制回源频率；
用 validator 控制回源体积；
用 private/no-store 控制安全边界；
用 URL 指纹解决“长缓存与发布”的矛盾。

总结

HTTP 缓存不是“加一个 Redis”或“在 Nginx 里 proxy_cache on”这么简单，它是一套有严格语义的协议机制：

Cache-Control 回答能不能存、能存多久、过期后能不能直接用；
ETag / Last-Modified 回答如何证明表示是否变化；
If-None-Match / If-Modified-Since 与 304 回答如何在确认未变时省略 body。

把这三层设计对齐后，静态站点、前后端分离入口、CDN 边缘缓存和公共 API 都能在带宽、延迟、一致性之间取得可解释的平衡。下次再看到“用户一直是旧页面”或“源站带宽无故升高”，先把响应头和一次条件请求抓出来——答案通常就在 Cache-Control 与校验器的协作里。

参考资料

IETF RFC 9111：HTTP Caching（新鲜度、验证、Cache-Control 指令语义）
IETF RFC 9110：HTTP Semantics（ETag、Last-Modified、If-None-Match、If-Modified-Since、304 Not Modified）
MDN：HTTP caching
MDN：ETag
MDN：If-None-Match
MDN：Cache-Control
Nginx 文档：ngx_http_headers_module（expires / add_header）
Nginx 文档：ngx_http_proxy_module（proxy_cache_revalidate、proxy_cache_use_stale、proxy_cache_valid）

Redis 缓存穿透、击穿与雪崩：原理、场景与工程解法

Mon, 13 Jul 2026 00:00:00 +0800

在高并发系统里，Redis 常常被放在数据库前面做读加速。一旦缓存设计不当，问题往往不是“Redis 慢一点”，而是数据库被瞬间打穿。工程上最常见、也最容易被混为一谈的三类故障是：缓存穿透、缓存击穿和缓存雪崩。

这三类问题听起来相似，根因却不同：

问题	典型特征	直接伤害
缓存穿透	查的是不存在的数据，缓存和 DB 都没有	恶意或异常请求反复打到 DB
缓存击穿	某个热点 key 刚好过期	同一时刻大量请求打到 DB
缓存雪崩	大量 key 同时失效，或缓存层整体不可用	系统级读流量直接压垮 DB

本文从现象、根因、可落地方案三层拆开，并结合 Redis 官方能力（SET 的 NX/EX、EXPIRE、淘汰策略、分布式锁模式）给出可复用实践。

一、先把请求路径画清楚

一个典型读路径是：

Client -> App -> Redis -> (miss) -> Database -> write back Redis -> response

缓存层的价值在于：

把高频读从数据库剥离出来；
用更低延迟响应热点数据；
给数据库争取容量和稳定性。

因此，任何“绕过缓存直接打 DB”的路径，都要被当成故障设计点来处理。

二、缓存穿透：查不存在的数据

1. 现象

请求的 key 在业务上不存在，例如：

用户 ID -1
商品 ID 999999999
被爬虫扫出来的非法参数

此时 Redis 没有缓存，数据库也查不到记录。如果应用只在“查到结果时才写缓存”，那么每次请求都会落到数据库。

2. 根因

穿透的本质不是“缓存过期”，而是：

空结果没有被负缓存（negative caching）保护。

3. 解法

方案 A：缓存空对象（最常用）

查库为空时，也写入一个短 TTL 的空值标记：

# 伪命令：空结果缓存 60 秒
SET product:999999999 __NULL__ EX 60

应用读到 __NULL__ 时直接返回“不存在”，不再访问数据库。

注意：

TTL 不要太长，避免真实数据刚创建后长时间读不到；
空值要有统一约定，避免和正常业务值冲突；
对写路径做缓存失效/更新，保证最终一致。

方案 B：布隆过滤器（Bloom Filter）前置拦截

对“可能存在”的 ID 集合做布隆过滤器：

数据写入时同步/异步加入过滤器；
查询前先判断“一定不存在还是可能存在”；
一定不存在则直接拒绝，不打 Redis/DB。

适合海量 ID、爬虫扫描、开放查询接口。代价是：

有极低误判率（把不存在判断成可能存在）；
需要维护过滤器更新与扩容。

方案 C：参数与权限校验前置

很多穿透其实是脏流量：

非数字 ID
超范围分页
未登录却访问私有资源

在网关/应用入口直接拦截，比把压力交给缓存更划算。

三、缓存击穿：热点 key 刚好失效

1. 现象

某个非常热的 key（首页配置、秒杀库存视图、热门商品详情）在某一瞬间过期。
下一毫秒，成千上万请求同时看到 miss，一起去查数据库，形成“单点热点打穿”。

2. 根因

击穿关注的是：

单个热点 key 过期窗口内的并发回源。

它和穿透不同：数据本来存在，只是缓存刚好空了。

3. 解法

方案 A：互斥重建（singleflight / 分布式锁）

只有一个请求负责回源重建，其他请求等待或短暂失败重试。

Redis 官方 SET 支持原子条件写入，可用 NX + EX 做互斥：

# 抢重建锁，5 秒自动过期，防止进程崩溃后死锁
SET rebuild:lock:product:1001 1 NX EX 5

流程：

读缓存 miss；
SET lock NX EX 抢锁；
抢到锁的请求查 DB，写回缓存，释放锁；
没抢到锁的请求短暂 sleep/重试读缓存，或返回旧兜底。

官方文档明确：SET key value NX EX seconds 是设置值并带过期时间的常用原子写法；SETNX 在新代码中更推荐用 SET ... NX 替代。

方案 B：逻辑过期（logical expire）

缓存 value 内嵌业务过期时间，物理 key 不过期或过期很久：

{
 "data": {"id": 1001, "price": 99},
 "expireAt": 1720857600
}

读取时：

未逻辑过期：直接返回；
已逻辑过期：返回旧数据，同时异步触发重建。

优点是用户几乎无感 miss；代价是要接受短暂脏读，并做好异步重建失败补偿。

方案 C：热点 key 永不过期 + 主动更新

对真正的超级热点，不依赖 TTL 被动失效，而由写路径/定时任务主动更新。
TTL 更适合普通数据；热点数据更适合“写时更新 + 监控”。

四、缓存雪崩：大面积失效或缓存层故障

1. 现象

两类雪崩最常见：

过期雪崩：大量 key 在同一时间点过期；
可用性雪崩：Redis 集群故障、网络分区、连接打满，导致缓存层整体不可用。

结果都是数据库在短时间内接到远超容量的读请求。

2. 根因

雪崩的核心不是某一个 key，而是：

缓存保护面在同一时间失效，流量失去缓冲层。

3. 解法

方案 A：TTL 加随机抖动

不要让同类数据使用完全相同的过期时间：

ttl = base_ttl + random(0, jitter)
# 例如 3600 + random(0, 300)

这样可以把过期曲线打散，避免整点集体回源。

方案 B：多级缓存与本地缓存

本地 Caffeine/Guava Cache 挡住进程内重复读；
Redis 作为分布式缓存；
DB 作为最终数据源。

本地缓存 TTL 更短，可显著降低 Redis 抖动对 DB 的传导。

方案 C：限流、熔断、降级

缓存层异常时，应用不能无脑回源：

对回源 QPS 做令牌桶/漏桶限流；
数据库错误率升高时熔断；
非核心接口返回兜底页/默认配置；
核心读接口优先返回短暂旧数据。

方案 D：正确使用 Redis 内存淘汰策略

当 Redis 用作缓存时，官方建议配置最大内存和淘汰策略，以便内存触顶时按策略驱逐 key，而不是写失败或无规划崩溃。常见策略包括：

allkeys-lru / allkeys-lfu：在全部 key 中淘汰；
volatile-lru / volatile-lfu / volatile-ttl：只在设置了过期时间的 key 中淘汰。

关键点：

缓存场景应显式设置 maxmemory；
按业务选择 LRU/LFU；
监控 evicted_keys、命中率、内存使用，避免“默默淘汰关键数据”却无人知晓。

淘汰策略解决的是内存压力下的可持续性，不能替代业务层的穿透/击穿防护，但能降低缓存层自身失控概率。

五、一套可落地的组合策略

真实系统很少只选一种方案，更常见的是分层组合：

1. 入口校验：挡住非法参数
2. 布隆过滤器/存在性索引：挡住明显不存在的 key
3. Redis 读：命中则返回
4. miss 时：
 - 热点 key：互斥重建或逻辑过期
 - 普通 key：允许有限并发回源
5. DB 空结果：写短 TTL 空缓存
6. DB 有结果：写缓存，TTL 加抖动
7. 全链路：限流 + 熔断 + 监控告警

伪代码示例

def get_product(product_id: str):
 if not valid_id(product_id):
 return None

 if bloom and not bloom.might_contain(product_id):
 return None

 cached = redis.get(f"product:{product_id}")
 if cached == "__NULL__":
 return None
 if cached is not None:
 return decode(cached)

 # 热点互斥重建
 locked = redis.set(f"rebuild:lock:product:{product_id}", "1", nx=True, ex=5)
 if not locked:
 time.sleep(0.05)
 return get_product(product_id) # 简化：重试读缓存

 try:
 row = db.query_product(product_id)
 if row is None:
 redis.set(f"product:{product_id}", "__NULL__", ex=60)
 return None
 redis.set(f"product:{product_id}", encode(row), ex=3600 + random.randint(0, 300))
 return row
 finally:
 redis.delete(f"rebuild:lock:product:{product_id}")

说明：

SET ... NX EX 用于短锁，避免击穿时并发回源；
空值缓存用于防穿透；
TTL 抖动用于打散过期，降低雪崩概率。

六、排查清单：线上怎么快速判断是哪一种

1. 先看指标

Redis 命中率是否骤降
Redis 连接数/超时是否升高
数据库 QPS、慢查询、连接池是否打满
是否集中在某几个 key，还是大面积 key

2. 判断路径

观察	更可能是
大量非法/不存在 ID，DB 查空很多	穿透
单个热 key 流量尖峰，过期瞬间 DB 飙升	击穿
整点或批次任务后大面积 miss	过期雪崩
Redis 超时/主从切换/集群异常同时发生	可用性雪崩

3. 临时止血

对异常查询参数限流；
对热点 key 预热并临时延长 TTL；
打开空值缓存；
给 DB 回源加总开关/配额；
非核心读降级。

七、设计原则总结

缓存不是数据库的影子，是保护层。 任何 miss 路径都要有预算。
空结果也是结果。 不做负缓存，就容易被穿透。
热点不能靠“碰巧没过期”。 要有互斥重建、逻辑过期或主动更新。
过期时间要工程化。 相同 TTL 是雪崩温床，抖动是基本操作。
缓存故障要有降级。 没有限流和熔断的缓存架构，只是把风险延后到数据库。
可观测性比“感觉很快”更重要。 命中率、回源 QPS、淘汰数、锁竞争都要可监控。

八、什么时候不该过度设计

不是所有系统都要上布隆过滤器 + 逻辑过期 + 多级缓存：

读 QPS 不高、数据几乎都存在：做好空值缓存和基础 TTL 即可；
写极少、读极多的配置类数据：适合主动更新 + 较长 TTL；
强一致要求极高的余额/库存：缓存只能做辅助，核心以数据库/专用组件为准，并明确一致性模型。

架构选择应匹配流量模型和一致性要求，而不是堆名词。

总结

缓存穿透、击穿、雪崩并不是三个神秘黑话，而是三条清晰的失败路径：

穿透：不存在的数据反复打穿 DB；
击穿：热点 key 失效瞬间被并发打穿；
雪崩：保护面大面积失效，流量失去缓冲。

把问题定义清楚后，解法会自然收敛到：入口校验、空值缓存、互斥重建、TTL 抖动、淘汰策略、限流熔断与监控。
Redis 提供了 SET NX/EX、EXPIRE、内存淘汰和分布式锁模式等基础能力，但真正决定系统稳不稳的，是你有没有把这些能力嵌进完整的读路径设计里。

参考资料

Redis 官方文档：SET 命令（含 NX / EX 等选项）
Redis 官方文档：EXPIRE 命令
Redis 官方文档：SETNX 命令
Redis 官方文档：Key eviction 内存淘汰策略
Redis 官方文档：Distributed locks 分布式锁模式

MySQL深度调优实战：从SQL到架构的全面优化

Fri, 26 Jun 2026 17:00:00 +0000

前言

MySQL 是最流行的关系型数据库之一，但在生产环境中，性能问题往往是开发和运维面临的最大挑战。本文将从 SQL 优化、索引设计、配置调优、架构优化四个维度，全面介绍 MySQL 性能调优的实战技巧。

一、SQL 优化

1.1 EXPLAIN 执行计划分析

EXPLAIN SELECT * FROM users WHERE age > 25 AND city = 'Beijing';

关键字段说明：

字段	说明	优化目标
type	访问类型	至少达到 range 级别
key	使用的索引	避免 NULL
rows	扫描行数	越小越好
Extra	额外信息	避免 Using filesort/temporary

type 访问类型（从好到差）：

system > const > eq_ref > ref > range > index > ALL

1.2 索引优化技巧

最左前缀原则

-- 联合索引 (a, b, c)
-- ✅ 命中索引
SELECT * FROM table WHERE a = 1;
SELECT * FROM table WHERE a = 1 AND b = 2;
SELECT * FROM table WHERE a = 1 AND b = 2 AND c = 3;

-- ❌ 无法使用索引
SELECT * FROM table WHERE b = 2;
SELECT * FROM table WHERE c = 3;
SELECT * FROM table WHERE b = 2 AND c = 3;

覆盖索引

-- 创建覆盖索引
ALTER TABLE users ADD INDEX idx_name_age (name, age);

-- 查询只需要索引字段，无需回表
SELECT name, age FROM users WHERE name = 'John';

索引失效场景

-- ❌ 函数操作
SELECT * FROM users WHERE YEAR(create_time) = 2024;
-- ✅ 改为范围查询
SELECT * FROM users WHERE create_time >= '2024-01-01' 
 AND create_time < '2025-01-01';

-- ❌ 隐式类型转换
SELECT * FROM users WHERE phone = 13800138000;
-- ✅ 类型匹配
SELECT * FROM users WHERE phone = '13800138000';

-- ❌ LIKE 左模糊
SELECT * FROM users WHERE name LIKE '%John';
-- ✅ 前缀匹配
SELECT * FROM users WHERE name LIKE 'John%';

-- ❌ OR 条件
SELECT * FROM users WHERE age = 25 OR name = 'John';
-- ✅ 使用 UNION
SELECT * FROM users WHERE age = 25
UNION
SELECT * FROM users WHERE name = 'John';

1.3 查询优化

分页查询优化

-- ❌ 慢查询（深分页）
SELECT * FROM orders ORDER BY id LIMIT 1000000, 10;

-- ✅ 延迟关联
SELECT o.* FROM orders o
INNER JOIN (
 SELECT id FROM orders ORDER BY id LIMIT 1000000, 10
) t ON o.id = t.id;

-- ✅ 游标分页
SELECT * FROM orders WHERE id > 1000000 ORDER BY id LIMIT 10;

JOIN 优化

-- 确保关联字段有索引
ALTER TABLE orders ADD INDEX idx_user_id (user_id);

-- 小表驱动大表
SELECT o.* FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.status = 1;

子查询优化

-- ❌ 子查询
SELECT * FROM orders WHERE user_id IN (
 SELECT id FROM users WHERE status = 1
);

-- ✅ JOIN 优化
SELECT o.* FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.status = 1;

二、索引设计原则

2.1 索引设计规范

-- 1. 选择区分度高的列
SELECT 
 COUNT(DISTINCT city) / COUNT(*) AS selectivity
FROM users;
-- 区分度 > 0.1 才考虑建索引

-- 2. 联合索引字段顺序
-- 区分度高的字段在前
-- 查询频率高的字段在前
-- 排序字段在最后

-- 3. 避免过多索引
-- 每张表索引不超过 5 个
-- 单个索引字段不超过 5 个

2.2 索引监控

-- 查看索引使用情况
SELECT 
 object_schema,
 object_name,
 index_name,
 count_read,
 count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database'
ORDER BY count_read DESC;

-- 查看未使用的索引
SELECT 
 object_schema,
 object_name,
 index_name
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database'
 AND index_name IS NOT NULL
 AND count_star = 0;

三、配置调优

3.1 InnoDB Buffer Pool

# my.cnf
[mysqld]
# Buffer Pool 大小，建议物理内存的 70-80%
innodb_buffer_pool_size = 8G

# Buffer Pool 实例数，减少锁竞争
innodb_buffer_pool_instances = 8

# Buffer Pool 预热
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup = ON

3.2 日志配置

[mysqld]
# Redo Log 大小
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M

# 刷盘策略
# 1：每次提交都刷盘（最安全）
# 2：每次提交写入OS缓存
# 0：每秒刷盘
innodb_flush_log_at_trx_commit = 1

# 双1配置（生产推荐）
sync_binlog = 1

3.3 连接配置

[mysqld]
# 最大连接数
max_connections = 500

# 连接超时
wait_timeout = 600
interactive_timeout = 600

# 线程缓存
thread_cache_size = 64

# 表缓存
table_open_cache = 4096
table_definition_cache = 2048

3.4 查询缓存（MySQL 8.0 已移除）

# MySQL 5.7 及以下
[mysqld]
query_cache_type = 0 # 建议关闭
query_cache_size = 0

3.5 排序和临时表

[mysqld]
# 排序缓冲区
sort_buffer_size = 4M

# JOIN 缓冲区
join_buffer_size = 4M

# 临时表大小
tmp_table_size = 64M
max_heap_table_size = 64M

# 读缓冲区
read_buffer_size = 2M
read_rnd_buffer_size = 8M

四、架构优化

4.1 读写分离

 ┌─────────────┐
 │ 应用程序 │
 └──────┬──────┘
 │
 ┌──────▼──────┐
 │ 代理层 │
 │ (ProxySQL) │
 └──────┬──────┘
 │
 ┌──────────────┼──────────────┐
 │ │ │
 ┌──────▼──────┐ ┌────▼────┐ ┌───────▼──────┐
 │ Master │ │ Slave 1 │ │ Slave 2 │
 │ (写) │ │ (读) │ │ (读) │
 └─────────────┘ └─────────┘ └──────────────┘

ProxySQL 配置示例：

-- 添加后端MySQL服务器
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES
(10, '10.0.0.1', 3306), -- 写组
(20, '10.0.0.2', 3306), -- 读组
(20, '10.0.0.3', 3306); -- 读组

-- 配置读写分离规则
INSERT INTO mysql_query_rules (rule_id, match_pattern, destination_hostgroup) VALUES
(1, '^SELECT.*FOR UPDATE', 10), -- 写操作
(2, '^SELECT', 20); -- 读操作

4.2 分库分表

垂直分库

用户库 (user_db)
├── users
├── user_profiles
└── user_settings

订单库 (order_db)
├── orders
├── order_items
└── payments

商品库 (product_db)
├── products
├── categories
└── inventory

水平分表

-- 按用户ID分表
orders_0 -- user_id % 4 = 0
orders_1 -- user_id % 4 = 1
orders_2 -- user_id % 4 = 2
orders_3 -- user_id % 4 = 3

-- ShardingSphere 配置
spring.shardingsphere.datasource.names=ds0,ds1
spring.shardingsphere.sharding.tables.orders.actual-data-nodes=ds$->{0..1}.orders_$->{0..3}
spring.shardingsphere.sharding.tables.orders.table-strategy.inline.sharding-column=user_id
spring.shardingsphere.sharding.tables.orders.table-strategy.inline.algorithm-expression=orders_$->{user_id % 4}

4.3 缓存策略

┌──────────┐ ┌──────────┐ ┌──────────┐
│ 应用程序 │───▶│ Redis │───▶│ MySQL │
└──────────┘ └──────────┘ └──────────┘
 │ │ │
 │ 1.查询缓存 │ │
 │──────────────▶│ │
 │ 2.返回缓存 │ │
 │◀──────────────│ │
 │ │ │
 │ 3.缓存未命中│ │
 │──────────────────────────────▶│
 │ 4.查询数据库│ │
 │◀──────────────────────────────│
 │ │ │
 │ 5.写入缓存 │ │
 │──────────────▶│ │

缓存更新策略：

// Cache Aside Pattern
public User getUser(Long userId) {
 // 1. 先查缓存
 String key = "user:" + userId;
 User user = redis.get(key);
 if (user != null) {
 return user;
 }
 
 // 2. 缓存未命中，查数据库
 user = userMapper.selectById(userId);
 if (user != null) {
 // 3. 写入缓存
 redis.setex(key, 3600, user);
 }
 return user;
}

4.4 表设计优化

-- 1. 选择合适的数据类型
-- ❌ 不推荐
CREATE TABLE users (
 id BIGINT,
 name VARCHAR(1000),
 age INT,
 status VARCHAR(20)
);

-- ✅ 推荐
CREATE TABLE users (
 id BIGINT UNSIGNED AUTO_INCREMENT,
 name VARCHAR(50) NOT NULL,
 age TINYINT UNSIGNED,
 status TINYINT NOT NULL DEFAULT 1,
 PRIMARY KEY (id),
 INDEX idx_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 2. 避免NULL
-- 使用 NOT NULL + DEFAULT

-- 3. 主键设计
-- 使用自增ID作为主键
-- 避免使用UUID作为主键（无序，影响插入性能）

五、监控与诊断

5.1 慢查询日志

[mysqld]
# 开启慢查询日志
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1 # 超过1秒记录
log_queries_not_using_indexes = ON

# 分析慢查询日志
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# 使用 pt-query-digest
pt-query-digest /var/log/mysql/slow.log > slow_report.txt

5.2 性能监控SQL

-- 查看当前连接
SHOW PROCESSLIST;

-- 查看InnoDB状态
SHOW ENGINE INNODB STATUS;

-- 查看表大小
SELECT 
 table_schema,
 table_name,
 ROUND(data_length / 1024 / 1024, 2) AS data_mb,
 ROUND(index_length / 1024 / 1024, 2) AS index_mb
FROM information_schema.tables
WHERE table_schema = 'your_database'
ORDER BY data_length DESC;

-- 查看索引使用统计
SELECT 
 object_schema,
 object_name,
 index_name,
 count_star,
 count_read,
 count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database';

5.3 诊断工具

# Percona Toolkit
# 安装
apt install percona-toolkit

# 分析慢查询
pt-query-digest /var/log/mysql/slow.log

# 检查重复/冗余索引
pt-duplicate-key-checker --host=localhost --user=root --password=xxx

# 查看索引使用情况
pt-index-usage --host=localhost --user=root --password=xxx /var/log/mysql/slow.log

六、调优清单

6.1 SQL 层面

所有查询都使用了合适的索引
避免了 SELECT *，只查询需要的字段
分页查询使用了延迟关联
避免了深分页（LIMIT offset 过大）
JOIN 查询关联字段有索引
避免了索引失效的写法

6.2 索引层面

高频查询字段都有索引
联合索引遵循最左前缀原则
区分度低的字段不建索引
定期清理未使用的索引
使用覆盖索引减少回表

6.3 配置层面

Buffer Pool 设置为物理内存的 70-80%
开启慢查询日志
设置合理的连接数
配置合适的日志刷盘策略

6.4 架构层面

读写分离（读多写少场景）
分库分表（数据量大场景）
引入缓存层（热点数据）
表设计规范化

总结

MySQL 调优是一个系统工程，需要从多个维度综合考虑：

SQL 优化是基础：写好 SQL 是最直接的优化手段
索引设计是核心：合理的索引能提升查询性能数倍
配置调优是保障：正确的配置能最大化硬件利用率
架构优化是根本：当单机瓶颈时，架构扩展是必由之路

建议按照本文的调优清单逐步检查，结合监控数据持续优化。

性能优化 on 吾爱主机

PostgreSQL Autovacuum：触发机制、表膨胀与参数调优

一、为什么会产生死元组

二、Autovacuum 的触发公式

三、先监控，再调参数

1. 找出死元组较多的表

2. 查看表与索引大小

3. 检查 Autovacuum 是否正在工作

四、针对热点大表做局部调优

五、为什么“调低阈值”仍可能无效

1. 长事务阻止清理

2. 清理能力跟不上写入速度

3. 误把内部可复用空间当成故障

六、生产调优清单

总结

参考资料

PostgreSQL B-tree 索引：结构、扫描方式与工程实践

问题背景：没有索引时，数据库在做什么

核心原理：为什么日常几乎都是 B-tree

B-tree 能加速哪些谓词

只有 B-tree 能“带着顺序”吐行

唯一性约束如何落地

扫描方式：同一条 SQL，三种常见“走路方式”

1）Index Scan：点查 / 高选择性范围

2）Bitmap Index Scan + Bitmap Heap Scan：中等选择性或组合条件

3）Index Only Scan：尽量不回表

覆盖索引与 INCLUDE

多列索引、部分索引：选型比“多建几个”更重要

多列 B-tree：最左前缀与效率

部分索引：只索引“值得索引”的子集

可复现实验：从建表到读懂 EXPLAIN

生产变更：CREATE INDEX CONCURRENTLY

常见坑与排查清单

工程实践建议（可直接落地）

总结

参考资料

HTTP 条件请求与缓存协商：ETag、Last-Modified 与 Cache-Control 工程实践

一、先分清：存下来 ≠ 可以直接用

二、新鲜度：Cache-Control 的核心指令

1. 响应侧最常用指令

2. Age 与“看起来刚生成”

3. 启发式新鲜度：别依赖“没写过期时间也碰巧能缓存”

三、校验器：ETag 与 Last-Modified

1. Last-Modified

2. ETag（实体标签）

四、条件请求：如何问“变了没有”

1. If-None-Match（优先，基于 ETag）

2. If-Modified-Since（基于时间）

3. 两者同时出现时谁说了算？

4. 304 Not Modified 到底省了什么

五、一张图串起完整路径

六、工程实践：按资源类型给策略

1. 带内容哈希的静态资源（最推荐）

2. HTML / 入口文档

3. 个性化或含凭证的 API

4. 可被 CDN 缓存的公共 API / 配置

七、服务端如何正确实现条件 GET

八、常见坑与排查清单

坑 1：no-cache 和 no-store 用反

坑 2：只配了长缓存，没有内容指纹

坑 3：ETag 在多实例间不一致

坑 4：中间层剥掉了校验器或改写了 Cache-Control

坑 5：API 被共享缓存误缓存

坑 6：304 后客户端仍像“没更新样式”

九、选型小结

总结

参考资料

Redis 缓存穿透、击穿与雪崩：原理、场景与工程解法

一、先把请求路径画清楚

二、缓存穿透：查不存在的数据

1. 现象

2. 根因

3. 解法

方案 A：缓存空对象（最常用）

方案 B：布隆过滤器（Bloom Filter）前置拦截

方案 C：参数与权限校验前置

三、缓存击穿：热点 key 刚好失效

1. 现象

2. 根因

3. 解法

覆盖索引与 `INCLUDE`

生产变更：`CREATE INDEX CONCURRENTLY`

1. `Last-Modified`

2. `ETag`（实体标签）

1. `If-None-Match`（优先，基于 ETag）

2. `If-Modified-Since`（基于时间）

4. `304 Not Modified` 到底省了什么

坑 1：`no-cache` 和 `no-store` 用反