>十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。


----

数据库偶尔变慢，是最让人头疼的事。

SQL 没改过，索引还在，服务器资源正常，但响应时间就是变长了。重启数据库、重建索引、优化 SQL——都试过了，没用。过了几天又好了，再过几天又慢了。

这种"偶尔变慢"的根因，很多时候不是 SQL 的问题，是统计信息过期了。

统计信息是优化器选执行计划的依据。统计信息过期，优化器就"瞎选"——本来该走索引的全表扫描了，本来该小表驱动大表的反过来了。一条跑了一年的 SQL，突然从 10ms 变成 10 秒，不是 SQL 变了，是优化器基于过时的统计信息选了错误的路径。

今天把统计信息过期的判断方法、修复流程、预防策略讲清楚。跟着这个流程走，下次数据库突然变慢，先查统计信息。


----

## 01 统计信息到底是什么


统计信息是数据库对自己的一份"体检报告"。

它记录的是：每张表有多少行、每列的数据分布是什么样的、索引的选择性如何、数据有没有倾斜。优化器生成执行计划的时候，不是"凭感觉"选路径，是"算代价"——全表扫描的代价是多少、走索引的代价是多少、哪种连接顺序最优——这些计算都依赖统计信息。

```
-- PostgreSQL/KES：查看表的统计信息
SELECT relname, n_live_tup, last_analyze, last_autoanalyze
FROM pg_stat_user_tables
WHERE last_analyze IS NOT NULL
ORDER BY last_analyze DESC;
```
统计信息不是实时的。数据在不停地增删改，但统计信息不会每次变更都更新。它是在特定时间点采样的快照。快照和实际数据之间的差距，就是统计信息的"过期程度"。


----

## 02 统计信息过期的真实表现


统计信息过期不是"数据库变慢了"这么简单。它的表现很具体：

### 表现一：执行计划突变


同一条 SQL，昨天走索引扫描，今天突然全表扫描了。不是因为数据量涨了多少，是因为统计信息里还记着"这张表只有 10 万行"，实际已经涨到 1000 万行了。

优化器算出来的代价：走索引 = 全表扫描，觉得全表扫描也差不多，就选了全表扫描。但实际数据分布已经变了，全表扫描的代价远大于预估。

### 表现二：关联顺序反转


两个表 JOIN，优化器应该选小表驱动大表。但统计信息里两张表的数据量反了——以为 A 是小表，实际 A 已经是大表了。结果大表驱动小表，嵌套循环扫描了几百万次。

### 表现三：索引选择性误判


某列的 distinct 值数量在统计信息里是 100，实际已经涨到 10000 了。优化器以为走这个索引能过滤掉 99% 的数据，实际只能过滤掉 50%。索引还是走了，但效果远不如预期。

### 表现四：分区裁剪失效


分区表按日期范围分区，统计信息过期后，优化器不知道数据集中在哪些分区，扫描了所有分区而不是只扫目标分区。


----

## 03 怎么判断统计信息过期


不要猜，直接查。

### 方法一：查上次分析时间


```
-- PostgreSQL/KES
SELECT relname, n_live_tup, n_dead_tup,
       last_analyze, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY last_analyze;
```
如果某张业务核心表的 `last_analyze` 是一个月前的，而这段时间一直在大量写入，统计信息大概率过期了。

### 方法二：对比估算值和实际值


```
-- 优化器估算的行数 vs 实际行数
SELECT relname,
       n_live_tup AS estimated_rows,
       (SELECT count(*) FROM pg_class WHERE relname = tables.relname) AS actual_check
FROM pg_stat_user_tables tables
WHERE relname = 'your_table_name';

-- 更直接的方式
SELECT count(*) AS actual_rows FROM your_table_name;
SELECT n_live_tup AS estimated_rows
FROM pg_stat_user_tables
WHERE relname = 'your_table_name';
```
如果估算值和实际值差了一个数量级，统计信息肯定过期了。

### 方法三：EXPLAIN ANALYZE 对比


```
EXPLAIN ANALYZE SELECT * FROM orders WHERE status = 'pending';
```
看执行计划里的 `rows`（预估行数）和 `actual rows`（实际行数）。如果差了好几倍甚至几十倍，统计信息就是过期的。

这是最准确的方法。不是看时间、看估算值，是看优化器在实际执行中的偏差。

### 方法四：死元组比例


```
-- PostgreSQL/KES
SELECT relname, n_live_tup, n_dead_tup,
       ROUND(n_dead_tup * 100.0 / NULLIF(n_live_tup + n_dead_tup, 0), 2) AS dead_ratio
FROM pg_stat_user_tables
WHERE n_dead_tup > 0
ORDER BY dead_ratio DESC;
```
死元组比例超过 20% 的表，统计信息需要更新了。大量 UPDATE/DELETE 后的表尤其要注意。


----

## 04 怎么修复：从紧急处理到长期预防


### 紧急修复：手动 ANALYZE


发现统计信息过期，第一步是手动分析：

```
-- 分析单张表
ANALYZE orders;

-- 分析整个 schema
ANALYZE;

-- 带详细输出
ANALYZE VERBOSE orders;
```
手动 ANALYZE 之后，再看执行计划，通常立刻就正常了。

>踩坑提醒：不要在生产高峰期跑全库 ANALYZE。ANALYZE 虽然不锁表，但会消耗 CPU 和 I/O。选在低峰期做，或者只 ANALYZE 核心表。


### 自动分析机制


PostgreSQL有自动分析（autoanalyze）机制。当一张表的变更行数超过阈值（默认是总行数的 20% + 50 行）时，自动触发 ANALYZE。

但自动分析有延迟。大批量数据变更后（比如一次导入 100 万行），autoanalyze 不会立刻执行，要等到统计信息收集器下次检查。这个间隙里，统计信息就是过期的。

所以批量操作之后，手动跑一次 ANALYZE 是好习惯。

```
-- 批量导入/更新/删除之后
ANALYZE orders;
ANALYZE order_items;
```
### 调整自动分析阈值


如果某些表的变更特别频繁，默认阈值太高，可以调低：

```
-- 设置更低的自动分析阈值
ALTER TABLE orders SET (autovacuum_analyze_threshold = 100);
ALTER TABLE orders SET (autovacuum_analyze_scale_factor = 0.05);
```
这样 orders 表只要有 100 行变更或者 5% 的数据变化，就会触发自动分析。

### 定时分析策略


对于核心表，不要依赖自动分析。用定时任务定期分析：

```
-- PostgreSQL 可以用 pg_cron
SELECT cron.schedule('analyze_core_tables',
    '0 3 * * *',
    $$ANALYZE orders; ANALYZE order_items; ANALYZE users;$$
);
```
每天凌晨 3 点分析核心表，保证白天工作时间的统计信息是新鲜的。


----

## 对比：自动分析 vs 定时分析 vs 手动分析


|方式|及时性|可控性|运维成本|适用场景|
|:-:|:-:|:-:|:-:|:-:|
|自动分析|有延迟|低|低|变更频率稳定的普通表|
|定时分析|按周期|中|中|核心业务表|
|手动分析|立即|高|高|批量操作后、紧急修复|

最佳实践是组合使用：自动分析兜底 + 核心表定时分析 + 批量操作后手动分析。


----

## 决策框架：按表的重要程度定统计信息策略


|表类型|变更频率|策略|频率|
|:-:|:-:|:-:|:-:|
|核心交易表|高|定时 + 批量后手动|每天 1 次 + 每次批量导入后|
|高频业务表|中|调低自动分析阈值|自动（阈值 5%）|
|普通表|低|依赖自动分析|自动（默认阈值）|
|历史归档表|极低|手动或关闭自动分析|按需|


----

## 深度分析：为什么统计信息问题容易被忽视


统计信息问题有几个"隐蔽"特征，让它成了数据库排查里最容易被漏掉的根因：

**第一，表象是"性能问题"，不是"数据问题"。** 数据库没报错，查询能出结果，只是变慢了。排查的时候很容易先想到索引、资源、锁，最后才想到统计信息。

**第二，问题是"渐变的"，不是"突发的"。** 统计信息不是一天过期的，是数据量一天天涨、统计信息一天天旧。到了某一天，优化器的决策突然偏离实际，但没人注意到这个渐变过程。

**第三，修复太简单，反而容易被忽略。** `ANALYZE` 一条命令就能修好。但正因为修起来太简单，很多人觉得"这能是什么大问题"，反而不去查是不是统计信息导致的。

**第四，自动分析给人"不需要管"的错觉。** 数据库有自动分析机制，大部分人就觉得不用管了。但自动分析的阈值和延迟在大批量变更场景下是不够的，这个认知差导致了很多"偶尔变慢"的问题。

统计信息管理不是"出事了再 ANALYZE"，是持续的运维动作。核心表定时分析、批量操作后手动分析、执行计划偏差大的时候主动查——形成习惯，就不会被统计信息问题偷袭。


----

## 总结


数据库突然变慢，先查统计信息。

看上次分析时间、对比估算值和实际值、EXPLAIN ANALYZE 看预估偏差——这三个方法能判断统计信息是不是过期了。

修复不复杂：手动 ANALYZE 立刻见效，长期靠自动分析兜底 + 核心表定时分析 + 批量操作后手动分析。

统计信息是优化器的眼睛。眼睛蒙了，优化器就走错路。保持统计信息新鲜，比事后优化 SQL 管用得多。

后续我会继续分享**分区表实战、主备切换与故障转移**这些话题，跟着我一篇篇学，数据库这块就没问题了。

有问题评论区见。


----

十五年数据库领域老炮。关注我，一起把数据库这件事搞明白。

十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。

数据库 EXPLAIN ANALYZE 实战：预估偏差怎么定位、怎么修复

同一条 SQL 昨天 10ms 今天 10 秒，SQL 没改过、索引还在，根因可能是统计信息过期。本文拆解统计信息过期的四种表现（执行计划突变、关联顺序反转、索引误判、分区裁剪失效），给出四种判断方法和从紧急修复到长期预防的完整方案。

数据库

数据库偶尔变慢且重启、重建索引无效？根因可能是统计信息过期，导致优化器选择错误执行计划。本文详解判断方法（对比预估与实际行数、EXPLAIN ANALYZE）、修复流程（手动ANALYZE）及预防策略（定时分析+阈值调整），助你快速定位性能问题。

代码解释

PostgreSQL

服务器

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

数据库 EXPLAIN ANALYZE 实战：预估偏差怎么定位、怎么修复-腾讯云开发者社区-腾讯云

数据库 EXPLAIN ANALYZE 实战：预估偏差怎么定位、怎么修复

数据库 EXPLAIN ANALYZE 实战：预估偏差怎么定位、怎么修复

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐